From the monthly archives:
{ Comments on this entry are closed }
One best practice for secure software development is to run your source code through a static analysis tool to try detect potential vulnerabilities during development, and a number of tool vendors have emerged to provide static products that are specifically tuned to security issues. However trying to galvanise your software organization to budget for this software, tolerate the inevitable disruption caused by the influx of consultants, pilot projects, and a slew of meetings can be a little daunting especially when you don't know how much of a benefit this activitiy is going to provide. If you write Java code and want to get a feel for the benefits of these tools without preparing powerpoints or talking to somebody from sales then you might want to concider taking a look at an open source project called Findbugs.
FindBugsis a static analysis tool that looks for problems in Java by analyzing the bytecode of your software. It can be run from the command line or integrated into your build system using ANT, Maven and there is a plugin for the popular Hudson continuous integration server . The main advantage of static analysis tools is that they allow you to analyze code without executing it so it is a great way to look at areas of your code that are difficult to reach with normal testing. It looks for something like 200 known patterns in your code that suggest something could be wrong. These range from the ability to trigger a null pointer exception to a JSP reflected cross site scripting vulnerability. These bugs are classified into 6 categories:
You can review all the patterns it reports here.
No single tool can be your code quality silver bullet and static analysis tools are no exception. The disadvantages of these tools is they don't understand what your software is trying to do, and their sense of context is extremely limited which can lead to a lot of false positives being reported which developers have to waste their time reviewing. One approach is to focus on reviewing only new bugs reported, and work on keeping the trend line as near flat as is possible. That way the backlog can be worked down over a period of time based on some sense of risk or other factors such as a correlation between customer detected issues, and Findbugs reported problems. From a security perspective this can be problematic because it only takes one issue to be exploited to cause a big problem. Threat modeling can help out here as it allows you to map threats to areas of code.
{ Comments on this entry are closed }
L’an passé j’ai lu The Personality Code the Travis Bradberry et réalisé le test de personnalité.
IDISC a été crée par un psychologue d’Harvard, Monsieur William Marston. Aussi inventeur de Wonder Woman.
Le résultat est que parmi les 14 personnalités, j’entre dans la case chercheur (Researcher). Voici les explications en anglais de ce type de personnalité :
As a Researcher, most of what you do is characterized by an utter reliance on logic and reason to solve problems, and a steadfast willingness to complete a project to the end without loose ends. You possess an unusual amount of determination and are highly task focused. You don’t mind working alone to accomplish goals, and are steadfast in your beliefs about what works and what doesn’t work. Just 4% of the population share this profile, including famous data hounds Warren Buffet and Jonas Salk.
|
Strengths:
|
Challenges:
|
How to make the most of your Researcher profile:
Suggestions for connecting with a Researcher:
D’après le test IDISC, chaque personnalité contient un anti-type. Ce dernier correspondant à un type de personnes avec lesquelles il risque d’avoir des étincelles… La bête noire du chercheur est le stratège.
What do you get when you bring two people together who are steadfast in their beliefs and always have a clear plan for the future? Unless their plans are matching, you’re bound to get fireworks. Since the Researcher and Strategist are motivated by different things – yet always have a plan for the future – their opinions of where to head are often at odds. The Researcher is characterized by his outright reliance on logic and reason when solving problems. He’s far more focused on tasks than people, and understandably unresponsive to persuasive displays of emotion. If you want to convince the Researcher of something, you better come with data. The Strategist, on the other hand, is primarily interested in people, and she uses her charisma to win people over to her way of thinking. Nobody likes talking to a brick wall, which is precisely what it feels like for a Strategist to talk to a Researcher – her most persuasive arguments go unnoticed. On the other side of the coin, the Researcher doesn’t understand why the Strategist can’t bring the facts forward, and is quick to assume that she’s hiding something to focus so fervently on, “anything other than the truth.”
Task-focused profiles often clash with people-focused profiles, and the source of resolution is generally fueled by the people-focused profile’s desire for harmony. This doesn’t work here. The Strategist may be focused on people, but she is quick to disdain those that don’t share enthusiasm for her ideas – and if anyone isn’t going to, it’s usually a Researcher wondering when she’s going to get the facts. Since both profiles are steadfast in their beliefs about how to get things done, the butting of heads that ensues can be fierce.
Is there anything the Researcher and Strategist can do to reconcile? Absolutely. It’s all about pace. You see, the Strategist is so willing to trust her gut that she grows impatient when others don’t do the same. But a Researcher isn’t going to budge here. Researchers just don’t offer quick decisions, and the Strategist has to understand that the Researcher needs time to collect the facts before he is comfortable offering an opinion. Whenever two people have trouble staying in sync, they need to check in with each other. Since the Strategist is usually going to be the one pushing to move things forward, she needs to stop and check-in with the Researcher every time that surge of impatience balloons in her belly. Make sure the two of you are talking about the same thing. The Researcher won’t hesitate to tell you the crux of what he’s thinking – so take what he says seriously.
If you think emotions can’t be measured, watch how quickly people are swayed by the Strategists ideas. She’s no pied piper – she’s convincing because she speaks directly to what people feel is important. The Strategist is also very good at planning ahead. She’s so good at it that people place great trust in what she thinks. So, you’re better off paying attention to what’s on her mind. If you’re hesitant to consider her suggestions, make sure it’s truly a logical fallacy and not your own resistance to change. The Strategist embraces change like a warm hug, and a Researcher can learn a lot from that. Finally, realize that the Strategist’s use of emotion to sway people’s opinion distracts from an important quality that she shares with the Researcher – perhaps more than any other profiles, the Strategist and the Researcher like to dot the i’s and cross the t’s. When things are going to hell in a hand basket, the Strategist is not only going to care about doing things right, she can convince the group to listen to a Researcher’s reason. Like the Researcher, the Strategist is a smart, logical thinker; when they find common ground in support of a plan, they make a formidable team.
Et vous quel est votre DISC ? 
{ Comments on this entry are closed }
Greg Ness touched off an interesting discussion when he asked “Will Virtualization Undermine Network Equipment Vendors?” It’s a great read summarizing how virtualization (and Cloud) are really beginning to accelerate how classical networking equipment vendors are re-evaluating their portfolios in order to come to terms with these disruptive innovations.
I’ve written so much about this over the last three years and my response is short and sweet:
Virtualization has actually long been an enabler for network equipment vendors — not server virtualization, mind you, but network virtualization. The same goes in the security space. The disruption caused by server virtualization is only acting as an accelerant — pushing the limits of scale, redefining organizational and operational boundaries, and acting as a forcing function causing wholesale reconsideration of archetypal network (and security) topologies.
The compressed timeframe associated with the disruption caused by virtualization and its adoption in conjunction with the arrival of Cloud Computing may seem unnatural given the relatively short window associated with its arrival, but when one takes the longer-term view, it’s quite natural. We’ve seen it before in vignettes across the evolution of computing, but the convergence of economics, culture, technology and consumerism have amplified its relevance.
To answer Greg’s question, Virtualization will only undermine those network equipment vendors who were not prepared for it in the first place. Those that were building highly virtualized, context-enabled routing, switching and security products will embrace this swing in the hardware/software pendulum and develop hybrid solutions that span the physical and virtual manifestations of what the “network” has become.
As I mentioned in my blog titled “Quick Bit: Virtual & Cloud Networking – Where It ISN’T Going…”
Specifically, as it comes to understanding how the network plays in virtual and Cloud architectures, it’s not where the network *is* in the increasingly complex virtualized, converged and unified computing architectures, it’s where networking *isn’t.*
Where ISN'T The Network?
Take a look at your network equipment vendors. Where do they play in that stack above? Compare and contrast that with what is going on with vendors like Citrix/Xen with the Open vSwitch, Vyatta, Arista with vEOS and Cisco with the Nexus 1000v*…interesting times for sure.
/Hoff
*Disclosure: I work for Cisco.
{ Comments on this entry are closed }
Balakrishna Narasimh and I were discussing the recent hoohaa on Public and Private Clouds when he made an observation on Twitter:
Starting to think public vs private clouds is misleading terminology. more meaningful distinction is single-tenant vs multi-tenant clouds.
I suggested that multitenancy can certainly be an attribute of Cloud deployment, but that I don’t see it as being a differentiator. I responded thusly:
So different business units in an enterprise don’t represent different “tenants?” They can be governed w/ diff. SLA, policy, $
My point here was that trying to use multitenancy as a way to distinguish between Public and Private Cloud deployments ignores the reality that in many large enterprises — many of whom who are beginning to architect and deploy Private Clouds — they think of their business constituencies as individual “tenants.” Each of these “tenants” often have different business requirements, service level requirements, cost structure and chargeback rates, policies, etc.
Food for thought.
/Hoff
{ Comments on this entry are closed }
|
Big Security Improvement for Cloud Computing - https://365.rsaconference.com/blogs...
|
{ Comments on this entry are closed }
{ Comments on this entry are closed }
{ Comments on this entry are closed }
{ Comments on this entry are closed }
The video from the talk Kevin Johnson and I did at DEFCON 17 called “Social Zombies: Your Friends Want To Eat Your Brains” is now up on Vimeo. If you missed us at DEFCON Kevin and I will be presenting an updated version at OWASP AppSec DC in November.
{ Comments on this entry are closed }
