Somebody asked me: "That's great that you have such a clear  vision of a future log management technology - but tell me first what future business problems will such 'ideal tool of the future' solve?"

First, I laughed and said: "Dude, look around, will ya? :-) There are plenty of log-related problems today which we are not even close to solving. We need to solve the problems of today first, before we can get to solving the future problems..."

So, what I consider to be the biggest log-related problems of today?

1. Not knowing what to log - whether  for compliance, tracking attackers or troubleshooting system problems. Remember all the comedy about "Tell me EXACTLY what to log for PCI?" If not, reread it!
2. Log volume  - there is too darn many log messages (seriously, 100,000 each second is a lot of log - but there is more at large companies!), and, which is worse, a lot of them are of unknown value to the users (might be useful, might not - but you never know in advance); thus, log clutter networks, systems and brains of security/system analysts.
3. Log diversity - logs all look different (at least while standards are being developed) and no single person have the skill set to understand  more than a few types. PIX admin groking SAP logs? No way!
4. In light of the above, just pure bad logs are also a major challenge - logs that miss a key piece of info (like the infamous "login failed" without the username...) or are useless in some other way are sadly common.
5. How about getting the logs from all the nooks and crannies where they are stuck  (think application logs here) - it is a problem if you want to achieve  (expand, rather) your operational awareness of applications.
6. Finally (not really, the list can go on and on), making sense of logs in  an automated fashion is still a #1 challenge  (IMHO) - we are getting better creating tools for humans to go thru logs (via reports and search), but log->conclusion process still requires a human, and a darn smart one.

Now, when you read the above think "end user", not "log management  vendor" challenges (I plan to post about these later). My idea of an ideal tool will seek to solve these and others.

Along the same line, this picture from 4th SANS Log Management Survey shows how people perceive the logging challenges:

as well as my logging challenges poll (analysis here):

Now, let's think of logging problems of the near future, say in 2 years.

But you'd have to wait for the next post for this :-)

Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?

I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example.  The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.

But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.

You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season.  J

One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.”  He was not alone, I assure you.

Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.

Richard Derwent Cooke wrote,   “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”

At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.

To be effective, training needs to happen in an environment:

·         Where expectations are clearly set (the SDL sets specific minimum requirements).

·         People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).

·         Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).

·         Where management models the behavior (recall the original BillG TWC memo).

·         Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).

Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.

To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.

 By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even  decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects.  And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.

And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior.  Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .  

We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.

I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.

So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.

• First, watch Dave Aitel beats the dead horse of academic security "research." Quote: "people who write papers in LaTeX two-column format end up saying the sky has a high negative trajectory." (other examples)
• I work for a vendor, but I am not "vendor scum." What is the difference? If you write a paper about a fake trend or about a non-existent phenomenon (that your marketing department created) with the sole intention of selling your product while masquerading your piece as "objective content", you will probably be called "vendor scum." Example: do you know why insiders are dangerous? Because of telnet and modems (no shit!) :-)
• Rich Mogul drop-kicks GRC. Then kicks it in the balls. Then steps on it. Fun read, for sure.
• Did somebody just utter "ROI"? Yeah - and that means katana blades sharpened, flamethrowers charged, pet trolls enraged :-) Yes, the beast is back - with a vengeance. Bruce Schneier hits it with +5 Flaming Blade, it doesn't die, it bites back ... again. If you love/hate ROI, read these. And Mike R comment here. Can we just replace the "R"-word with "economic measure of security" or "security efficiency?"
• Does anybody with at most half a brain believes that "almost one out of every three individuals who were informed of a data security compromise involving their personal data have ceased doing business with the company that experienced the incident" (source here and more commentary here)? Well, same people who believe FBI/CSI surveys, I guess :-) UFO? Spoon bending? Santa Claus anyone?
• NEWSFLASH!!!! Employees needs to be monitored!!! Wow!!! Reeeeally? Well, it is news to some people. Mike R makes good fun of them here.
• Harebrained paper about PCI and using cards (credit and debit), which serves as a perfect illustration of how some people perceive risk. Repeat after me: you are not liable for mis-use of your credit card, your bank is. Debit card? Very different story!
• So, risk, yes. A really good piece about risk is here. Then again, it is RiskAnalys.is? :-) More on risks of compliance stuff (also good) is here.
• Richard clearly, succinctly, brilliantly explains the "security chasm" here by commenting on Greg's article (featured in my previous FRoS): "The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems."
• Security reading? Nah, fun security listening (that is, unless you are sick of hearing about RSA 2008 again), where we discuss - yes, you guessed right! - past RSA 2008 show.

Enjoy!

Implementations of knowledge-based authentication (KBA) -- asking "secret", out-of-wallet questions that presumably only the end user knows the answers to -- on the Web have been on the rise in the past few years, particularly in online financial services, as part of efforts to fulfill FFIEC guidelines for additional risk mitigation measures that address the inadequacies of single-factor authentication. The concept of layered authentication -- the riskier the transaction, the more stringent the authentication measures -- is related to this, and KBA can be readily (and simplistically) adapted to layered authentication by simply increasing the number of secret questions that the system asks.

Of course, as a standalone method of authenticating users at login, asking out-of-wallet questions in addition to username and password doesn't rise to the level of strong (two-factor) authentication, since they're all variations on "what you know". So from a security standpoint it's difficult for KBA to really provide identity assurance. But isn't ease of use and peace of mind for end users that's driving financial institutions to implement KBA? (Let's put aside for a moment any cynicism about KBA being a cheap alternative for the FI.)

Apparently, though, there's a point at which users' confidence that the bank is protecting their assets tips over into suspicion that the bank's security isn't up to snuff or even that a fraudster is pumping them for personal information. And then there's the annoyance factor: the inconvenience in terms of the time and effort to remember all of the PINs, passwords, and answers and jump through those hoops. It's as if the typical Internet banking customer is a tender orchid needing just the right conditions to flourish.

The only problem is that in most cases this isn't true. Buck up and spend the cash on a real two-factor authentication system, mandate its use, and customers will adapt -- even thrive. There are enough different methods of two-factor our there that the difficult decision should not be whether to implement two-factor, but which form factor to choose.

In the aftermath of September 11th, we realized that, tragically, we were presented with an opportunity to find out whether our lab research could predict how the country as a whole would react to the attacks and how U.S. citizens would perceive future risks of terrorism. We did a nationwide field experiment, the first of its kind. As opposed to the participants in our lab studies, the participants in our nationwide field study did have strong feelings about the issues at stake -- September 11th and possible future attacks -- and they also had a lot of information about these issues as well. We wondered whether the same emotional carryover that we found in our lab studies would occur -- whether fear and anger would still have opposing effects.

In pilot tests, we identified some media coverage of the attacks (video clips) that triggered a sense of fear, and some coverage that triggered a sense of anger. We randomly assigned participants from around the country to be exposed to one of those two conditions -- media reports that were known to trigger fear or reports that were known to trigger anger. Next, we asked participants to predict how much risk, if any, they perceived in a variety of different events. For example, they were asked to predict the likelihood of another terrorist attack on the United States within the following 12 months and whether they themselves expected to be victims of potential future attacks. They made many other risk judgments about themselves, the country, and the world as a whole. They also rated their policy preferences.

The results mirrored those of our lab studies. Specifically, people who saw the anger-inducing video clip were subsequently more optimistic on a whole series of judgments about the future -- their own future, the country’s future, and the future of the world. In contrast, the people who saw the fear-inducing video clip were less optimistic about their own future, the country’s future, and the world’s future. Policy preferences also differed as a function of exposure to the different media/emotion conditions. Participants who saw the fear-inducing clip subsequently endorsed less aggressive and more conciliatory policies than did participants who saw the anger-inducing clip, even though the clip was only a few minutes long and participants had had weeks to form their own policy opinions regarding responses to terrorism.

So, to summarize: we should not be fearful of future terrorist attacks, we should be angry that our government has done such a poor job safeguarding our liberties. And that if we take this second approach, we are more likely to respond effectively to future terrorist attacks.

I, Craig Balding, Am A Former Security Wannabe.

Well..that’s not entirely true.

The truth is that you never really stop being a security wannabe - no matter how others perceive you. Its simply that if you keep moving forward, you become less of a wannabe than the people moving slower than you :-).

In the course of my security journey I have been privileged to meet and work with some of the smartest security people across the globe.

From reverse engineers at the cutting edge, to digital crime fighters of the highest caliber. All of these people shared one thing in common - at some point, they too were a ’security wannabe’.

The Questions This Blog Will Try To Address

• How do you make the transition from security wannabe to paid security security wannabe?
• What skills/experience do you need to pick up along the way?
• Are there ‘fun’ jobs in the IT security industry? What “cool stuff” do people get to do? What is a typical day like for someone employed as a ‘your-future-job-role’
• How do you do some of the things you do? (e.g. Incident Response, Penetration Testing)

If digital security sounds exciting to you, or you’re already an aspiring security wannabe then you are at the right place!

Or if you’ve always been told that security is just about ‘passwords’ and ‘antivirus’ then let me show you behind the curtain.

Finally, if you - like me - claim to be a former security wannabe…welcome home ;-).

Enjoy the blog,

Craig

P.S Something you want to see? Leave a comment or email me.

I see a Maslow's heirarchy in the evolution of security posture of a company. Each posture is determined by the line of business [type of industry] and the size of business [start-up or mid-size or large publicly traded].

1. Don't Care for Security - These are early stage companies that don't have time for security since they are busy getting their product out. There are mid-size to large companies that demonstrate this posture [at their own risk]. Ironically, early stage or start-up companies should take utmost care in protecting their intellectual property [sensitive data] else they will loose their competitive advantage.

2. Security Exists - These are companies that acknowledge that security is important and realize that some reasonable measure needs to be taken to protect their intellectual property. Websites that have begun e-commerce transaction on their website realize the importance of security of their customers' data, belong to this category. There are companies that have realized the importance of security since customers have started demanding security in their products [Why would you buy a book from a small online book vendor vs. Amazon? A small online vendor has to work harder to convince customers about security]. These are the companies that are drafting a security architecture and working toward Basic Security posture.

3. Basic Security - These are companies that have the knowledge that "Security Exists" and have acted  to make sure that there is basic security to protect their intellectual property. These are mostly small to mid-size publicly traded companies. They use layered security approach: Firewall, IDP and Anti-Virus. These companies are not competent in handling security incidents  effectively. They have no plans for what if bad stuff happens.

4. Managed Security - These have incorporated dedicated staff to manage the lifecycle of security components. They have the well defined procedures to handle security incidents. There is a small budget allocated to the information security team, but management does not perceive the value of the team. Security is not viewed as a risk management framework for the business.

5. Constantly Improving Security - These are companies that recognize that security posture is a constantly moving target. Senior management is committed to the security program. Security is viewed as a holistic program to mitigate business risk due to information security breach. They have well defined security policies and security procedures. They have security awarenes program for employees. They audit their security practices against standards [such as ISO 27001, COBIT]. These are companies that are ISO 27001 compliant or heading in that direction. They routinely audit security practices, identify non-conformances and act on it to improve and this process goes on and on. These companies tend to be mid-size to large publicly traded companies. Financial institutions strive hard to be in this category. Moreover, companies that are concerned with running an efficient security program employs this model.

Here are some facts around these postures:

1. At the top of the pyramid is posture #5, there is no short-cut to it.

2. There is a cost involved in transitioning from lower posture to the next higher posture.

3. The cost of transitioning increases exponentially as as you advance through the postures. 

4. When #5  is attained there is efficiency and economies of scale hence reduces the cost of the security program and reduces business risk significantly at a low cost.

Here are reasons why Self-Defending Network is a far-fetched idea:

1. Security is not just technology alone. Security is people, security is process, security is technology.

2. The threats are evolving and moving up the stack. The motive of hackers is financial gain, not ego display as in the past. The exploits are very focused & covert vs. widespread & ostentatious. It is hard for Self-Defending network to identify distinguish a focused & covert traffic from a normal traffic.

3. Network is an ecosystem of software and hardware from multitude of vendors. A Self-Defending Network cannot keep a tab on the vulnerabilities across the board.

4. Number of vulnerabilities is not finite. The permutations and combinations of vulnerabilities add more complexity. Self-Defending Network cannot keep a tab on all those.

5. The components (Firewall, IPS, NAC Et. Al.) of Self-Defending network should evolve synchronously in order to inter-operate and still be effective which is less than likely.

6. Self-Defending network cannot understand your business systems and prioritize risks.

7. Self-Defending Network cannot provide physical security to itself.

and many more..

Building and maintaining a network which can shield network from threats that you perceive as risks to business [within the limits of your budget] is practical.

At RSA 2007 compliance phrases were flying all over, Real-time Compliance, Continuous Compliance, Sustainable Compliance, ad-nauseum. The famous McAfee party was my savior, I downed few glasses of wine and that helped me regain my orientation. Riding back home on the cal-train I was wondering if customers buy vendor phrase or real solution that address their concern. The vendor phrase seems to be an eternal winner.