Recently in Security Category

With the end of July close by and the beginning of August looming at the end of my calendar, the Black Hat and the Defcon conferences are rapidly approaching. For me, it is the time of year where I get to hang my suit and put on simple clothes to go hang out with many of my friends in the security arena. As an added bonus, I get to attend some world-class caliber talks about new types of attacks, new tools and generally a new refresh about what we are up against. Anyone who is serious about making a career in information security should attend both conferences at least once.

The stuff I do for a living is guiding my organization to be successful at keeping its valuable information assets secure. To do that, my days mostly revolve around a combination of meetings in which we talk about developing and implementing security strategy, setting and implementing policy, working on things like vulnerability scanning, patch management, network situational awareness and managing security incidents. There is a lot more, but that's not all that relevant right now ;)

Whenever the big summer conferences approach, the technical side of my starts to speak up more. Suddenly, I want to be more involved with activities such as penetration testing, forensics, real-time log analysis, etc. I typically start annoying the people who are responsible for daily operations when that happens, but as it is the law of the land, I generally win those fights and I get to scratch my itch.

This year is no different, but as things go, I just cannot find the time to get my hands dirty. The closest I was able to do was throw out a few Tweets in which I stated that solving non-tech challenges is rewarding, but in the end it comes down to hard core tech. No CISO should ever forget that. I also said that a well-designed and well-built network in a poorly run organization still has a chance of being secure. The other was around not so much. In a private tweet, I also said that developing and implementing policy is critical too, but that having a great policy without the technology to back it up is a guaranteed fail, which having a good technological infrastructure to work on, technology without policy will work for a while.

Now, to pull out a cliche, as a CISO, it is my job to balance technology, processes and people to navigate my organization to a point where its residual information security risk is of an acceptable level. It is important to realize that all three P's are necessary to be truly successful, but if I had to pick, I would much rather work in an organization that has great technology and knows how to use it, but may be weak on the policy/people end, than work in an organization that is driven by handbooks, policy and procedures, but is weak in technology and people.

I have recently been invited to teach my introductory computer and network security class in the Spring semester. The class is a "high 300"-class, and I'm looking forward to refreshing my material.

For as many years as I have been active in this field, I have observed a serious disconnect between technical information security practitioners and the material that is taught at colleges and universities.

As it happens to be, I will be heading out to Las Vegas at the end of this month (July) to attend the Black Hat Briefings and some of Defcon 18. At the risk of launching is understatement of the year, I am fairly sure that it should not be too hard to find security practitioners with an opinion at those venues,

So, consider this post as a call to action.

If you want to help me out by sharing your thoughts on what a full-semester 3 credit undergraduate class on computer and network security should look like, please hit me up and tell me exactly how you feel. The class is targeting a mix of computer science majors and management of information systems majors.

You can reach me via the feedback option at the bottom of each page on this site, but using the comments fields, or by contacting me on Twitter. My handle is @leune. I look forward to hearing anything from technical skills that should be taught, reading materials that I should review, or even conferences that I should send people to. Any feedback is good feedback!

On one of my recent trips back from New York City to my office, I had to spend some time on Penn Station to wait for my train to arrive. Invariably, whenever that happens, I end up in a book store. Although, I usually do not end up buying anything, this time I picked up a copy of Atul Gawande's The Checklist Manifesto. In the book, Gawande presents example after example to explain why just about any procedure can be improved by using checklists.

Checklists provide the minimal steps required to execute a procedure successfully. They do not have to always be written in full, and should not go into extreme details describing every step to take, but they should focus on certain key steps that should always be followed. Arguably, the most well-known form of checklists are the ones used by pilots. These checklists cover routine circumstances, but specific exception checklists also exist. The checklists typically do not focus on how to do things, they do provide a form of reflection to whomever uses them to ensure that the what has been done.

Information security practices may also benefit from checklists. Keep in mind the lesson from the book: checklists should be simple to understand, focus on critical steps, describe what needs to be done and not how to do it, and most importantly, be used consistently.

In my security practice, I often use very simple checklists. Common items include:

☐ Notify CIO

☐ Inform Helpdesk

☐ Create tracking ticket

☐ Activate CSIRT

These checklist items are simple to understand, do not assign specific responsibility for who should execute the steps, and do not provide any guidance about how they should be executed. Yet, they are unambiguous, and when steps are omitted from them, it may come back to haunt you.

Some of the common objections against using checklists raised by critics are:

• "I do not need a checklist to tell me how to do my job." Maybe, but remember that the checklist does not specify how to do a job. They provide reminders of all the steps that need to be gone through, and they will provide whoever is using them with the assurance that all steps were followed. Especially with highly repetitive jobs that are executed dozens of times a day, it is easy to miss a step or to cut a corner. Conversely, procedures that are invoked very rarely run the risk of being executed incorrectly. Checklists will ensure that defined processes are executed completely and consistency, rather as shot from the hip. I find that incident response work typically benefits from checklists.
• "Checklists slow me down." That is part of the whole idea. Checklists will stop people from going on autopilot and force them to actually think about what they are doing and how they do them.
  
• "I do not see the value of checklists". Completing checklists will provide job metrics, especially if exceptions are noted. In addition, they may provide a documentation trail about the work that is done. Finally, the first time that a checklist actually catches an omission before it turns into an incident in its own right, their value will be made obvious.

The book was a very pleasant read, and I highly recommend it. Pick it up here (hardcopy) or

While assessing my infrastructure, I came to the conclusion that it is time to start making work of a few things:

• increasing operational efficiency by selective and targeted automation of log review, thereby freeing up valuable human resources to work on more interesting projects;
• increasing (near) real-time situational awareness of my infrastructure;
• increasing the ability to conduct log-based forensics;
• increased scrutiny and enforcement of log retention policies.
  

Note that compliance is missing in this list. Partially that is because doing these things well will lead to an increased compliance posture, and partially it is caused by the fact that I do not have compliance regulations that require me to implement technologies like this.

Anyone familiar with the field will see that this a textbook use case to start looking for a log management solution, an event management solution, or maybe even a full SIEM.

Since I have done SIEM projects in a previous job, I was a little reluctant to start a new one. SIEM projects typically involve many operational groups, which makes them complicated to execute, and the SIEM market is generally on the pricey side. Adding a SIEM will also add a layer of complexity, if done wrong.

However, after some consideration, I decided that it was time to do start a new project. In order to avoid wasting my time, I built several go/no-go decisions into my expected timeline.

Like many IT projects, a SIEM project is not something that can be rushed. From the point of project initiation, I decided to take 1 year to go through the process of research, budget acquisition, requirements formulation, scoping, vendor presentations, contract negotiations, etc. to the point where a product has been purchased and implementation could start.

Twelve months is a long time, but it is necessary to take the time and to do it right. Once you commit to a SIEM product, you had better take it serious, or else it will fail.

While I am now at about 3/4 of my project, and my potential vendor list has been narrowed down quite a bit, I have not yet made a final selection about which product/vendor to select, if I select one at all.

After an overdose of sales rep speak ("single glass pane", "drill down", "30 thousand feet overview", "customizable dashboard", etc.), I can say that most products that I have reviewed have made some nice progress since I looked at them 5 years ago. Interesting to see is that, while I followed the same evaluation process back then, the outcome is completely different this year. That difference can be explained by a combination of market movements, a different workplace, SIEM technologies maturing, and a better understanding on the implications of doing something like this on my part.

The SIEM market seems to be developing nicely, and is slowly reaching a level of maturity.

It seems that I am not the only one thinking about these things lately. The guys over at Securosis have been posting a nice series of posts on SIEM selection, as has Rocky DeStefano over at Security Operations by Visible Risk. In the midst of this, Andrew Hay takes a job at the 451 Group as the Senior Analyst primarily responsible for the SIEM, Log Management, GRC, Forensics, Vulnerability Analysis, and Penetration Testing portfolios; the Gartner Group decided to release is 2010 magic quadrant for Security Information and Event Management; and LogLogic announced that they are cutting their pricing in an attempt to push the market towards a more cost effective solution for SEM/SIEM.

We live in interesting times.