Information Security Strategy

Exercise works...

2010-08-18T19:53:48Z

...No, although I have heard rumors that it might be a good idea too, I am not talking about the kind of exercise that involves push-ups or running a mile before breakfast. I am talking about exercising emergency plans before they are actually needed.

Today I was able to get the entire IT management team together to run through a tabletop exercise of the IT business continuity plan. The exercise was received very well and I think the participants not only had fun going through the scenario that I set out for them, I also think it boosted their confidence, worked towards increasing team spirit, and (of course) identified some areas in which we need to improve our processes.

Those of us who have played tabletop role playing games such as Dungeons and Dragons (go ahead, admit it!) will feel right at home in a tabletop business continuity exercise. The goal of a tabletop is to practice policies and procedures without having to break out the big guns, pull staff from their normal routine, or disrupt production processes. As a result, tabletops can be a relatively cheap, but still effective way to go over a scenario.

The chain of events was fairly simple. I set the story to emulate a small fire in a main server room to take out a core switch, which took with it remote connectivity and some telephone services. The fire was small and contained relatively fast, but it was not possible to do a full damage assessment as a result of a Fire Marshall declaring the site off-limits for investigation.

For myself, I had set the following training goals:

- Train the participants to recognize when 'events' turn into something bigger and some form of emergency operations need to be activated.

- Train the participants in the decision-making process that leads up to formally declaring an incident.

- Train the participants in designating emergency roles and responsibilities

- Train the participants to communicate fully, clearly, and unambiguously, not only within the technology team, but also with the user community at large.

Because many of us in IT are so used to dealing with end-user emergencies all day long, it often takes time to recognize that something bigger is going on and that a response must be escalated. As always, that turned out to be the case here too, but lessons were definitely learned and I am confident that we will do much better next time.

All-in-all, I think we had a good exercise and, once again, we are better prepared for when events really take place.

BlackHat and Defcon Guidance

2010-07-24T00:09:37Z

Service announcement:

If you plan on bringing a computer to Defcon and/or Black Hat, think twice about plugging it into the conference network or connecting to the conference wireless networks.

If you do insist on bringing a machine to the conference floor, you had better take a pristine image without any form of even remotely sensitive data on it.

Do not communicate any authentication information at all, unless you are POSITIVE that it is protected.

If you rely on a VPN-like connection to tunnel your traffic, make sure that you authenticate BOTH SIDES of the tunnel.

Do not forget to turn off the WiFi and the Bluetooth settings on your mobile devices. Leave that iPad at home or in the room.

I am not too worried about using the hotel's network at Ceasar's, but don't even consider plugging it in if you stay in the Riv.

Black Hat and Defcon approaching rapidly

2010-07-19T20:01:46Z

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.

Teaching again

2010-07-08T20:34:24Z

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 Checklists

2010-06-25T17:44:50Z

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

Implementing SIEM

2010-05-19T17:46:08Z

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.

Developing a strategic information security plan

2010-05-07T14:31:35Z

With the summer approaching rapidly, it is time to start working on my next strategic plan. As a refresher from business school: strategic planning is the process by which an organization's long-term goals and objectives are identified and documented. Exactly how long "long-term" actually is depends on your environment. In my case, working of a three year strategic plan seems to make the most sense.

Goals are much like policies; they should be broadly defined, describe a desired outcome, be to the point, and (in most cases) be technology-neutral.

Information security strategic plans must not exist in a vacuum. Instead, the information security organization is typically part of a larger unit (IT, Internal Audit, etc.), which in turn is part of the overall organization. Any goals and objectives that are defined in the information security plan should be in alignment with those organizational goals.

In order to develop an effective information security plan that will be carried by the organization as a whole, it is often best to develop the plan top-down. In other words, start with the organization's goals and derive your information security goals from them. It is completely acceptable to identify some information security goals that are not derived directly from your organization's strategic plan, but the information security goals should never be in conflict with the organization's goals.

Goals are made specific by defining realistic and measurable objectives. Each objective typically leads to one or more initiatives that play a role in achieving the objective. By measuring how well initiatives are achieved, a picture forms of how well goals are realized.

When defining a strategic plan, care must be taken not to end up in a mindset that will reject anything that is not directly related to it. Your organization's daily operations must continue, and new things will pop up that must be addressed also. Especially in the information security field, where new threats manifest themselves daily, the strategic plan should not compromise the flexibility of your response organization. Having said that: the plan will provide guidance going forward and determine future directions.

Many organizations, mostly governmental bodies, publish their information security strategic plans to the public and they can be used as a reference.

So: how would this work? Let's give it a go. Some conventials. Roman numerals are used to enumerate goals (I, II, III, IV, etc.). Latin numbers are used to enumerate goals (1, 2, 3, 4, etc). Latin letters are used to enumerate initiatives (a, b, c, d, etc.). Note that Objectives are listed under their respective Goals, but since initiatives can contribute to objectives associated with multiple goals, they are numbered independently.

Goal:
I).    Improved network forensics capabilities.

Objective:
I.1) Capturing of session data on networking core
o    Collect network flow data from all network core devices by end of month 9

I.2) Logging on all network devices, starting at the access layer.
o    100% of core switches, routers, and firewalls to generate logging by end of year 1
o    100% of all network components to generate logging by end of year 2

I.3) Central collection of all security logs.
o    100% collection of all generated network device logs by end of year 1
o    100% collection of all server logs by end of year 1

Initiatives:
a)    Purchase, install and configure a server to receive, store, analyze and process network flow data and log data (contributes directly to I.1 and I.3)
b)    Discover and document all sources of security logs (prerequisite to c)
c)    Configure all security log sources to generate logs and to transmit them to central log collection point (contributes directly to I.1, I.2 and I.3)
d)    Configure all core network devices to generate session logs and to forward them to central log collection point (contributes directly to I.1, I.2 and I.3)

The initiatives can now be used for budgeting purposes and to establish an operational plan.

Penetration Testing in the Real World

2010-05-04T01:07:11Z

The crew over at Offensive Security has taken the time to produce and publish a 17 minute technical video describing a summarized version of an actual penetration test. While several mistakes were clearly made by the target network, none of the errors were unheard of, even in well-managed corporate environments.

This is probably one of the best examples of penetration testing that I have seen in quite a while. The story is told by "muts" from Offensive Security, which is a training and consultancy company that I highly respect.

Offensive Security's training offerings are high quality for a low price, and definitely something that I highly recommend to look into (Disclaimer: I hold the Offensive Security Certified Professional Certification).

While the course content may not be 100% state-of-the-art, the attacks and exploits in it are still highly applicable in many organizations. Furthermore, the way-of-thinking that is introduced by this class is unparalleled.

After viewing the video, I think you'll have a whole new perspective on these things.

Slide decks posted

2010-05-03T19:42:06Z

The month of April was a month in which I had three public speaking appearances. It started out on April 16 when I addressed the New York Higher Education Technology Forum at Hofstra University. The talk tried to drill home the point that all this Cloud stuff is all nice and fluffy, but that we, as cloud consumers, must make sure that our vendors deliver better service for less money. If we fail to do that, we are not making any progress, and Cloud will just be another concept that is doomed to fail.

The second talk was on April 20 at SOURCE Boston, where I was in the fortunate position to mentor a panel about career development, and especially about the role that mentors in that process.

In the third and final talk, on April 29, I addressed a gathering of non-technology people about the risks of social networking, and how to mitigate the risk for themselves. The most important point that I tried to make in that presentation was that on social networks, people may actually read what you write.

Both presentations are available for download, although they might not do you much good without the narrative.

SOURCE Boston 2010

2010-04-30T01:06:43Z

SOURCE Boston has been over for almost a week. Looking back at the event, I can only come to the conclusion that, once again, the level of the presentations exceeded my expectations. While the conference is fairly small, with only between 250 and 300 persons in attendance, the talks were of high quality and the people who attended just about all mattered. Despite the fact that several speakers were stuck in Europe as a result of the volcanic eruptions in Iceland, it was still very worth while to attend.

As the talks are posted online in a few weeks, I'll let you form your own thoughts about them and I'll make sure to publish a reminder when the do become available.

This year, I was in the fortunate position to host a panel session on Wednesday night. The panel discussion revolved around the usefulness (or lack thereof) of mentors in furthering careers in the information security field. Some very interesting comments were made during the session, and we are going to try spinning something up again next year.

From the life of a CISO...

2010-04-20T14:39:44Z

Two things you never want to hear (especially on the same day):

* From an IT director to the CISO: "There is no need to involve your group in the project yet-- we have not even decided on the product!"

* (overheard) Admin: "Do you think we should tell the security officer about this?" Manager: "no, he did not get in."

Now, I could do a full writeup about how important it is to include information security officers from before the planning stage of every project, and how even the slightest sign of unusual behavior should be brought to the attention of a security person, but I will not do that. These two quotes should speak for themselves.

Information Security in the Cloud

2010-04-16T13:11:29Z

Today, I will present "Information Security In The Cloud" at the New York Higher Education Technology Forum. The presentation will deliver a high-level overflow of some things to keep in mind when moving to a cloud-based infrastructure.

The one point that I hope to get across is that, in order to create real value, CIOs must hold cloud service providers to at least the same levels of expectation as they hold their internal IT organization. In other words, when a CIO expects an uptime from 99.99% from the internal IT group, a cloud offering should be able to deliver the same. If a CIO expect to run an infrastructure component for $25,000 (all-inclusive), the cloud offering should be at most the same price. If the CIO expects regulatory compliance and performance monitoring from the internal groups, he should do the same from a cloud offering.

Too often, business are willing to accept a lower level of quality from cloud offering. For example, some of the cloud providers that I have worked with directly typically do NOT promise an minimum uptime, or when they do, it is at most 99.9%. Taking such of offering would often reduce the quality of the end-user service offerings.

The presentation outline is as follows:

- Introduction
- Assumptions
- Traditional information security
- Cloud Considerations
- Top Threats (based on the Cloud Security Alliance report of March, 2010)
- Recommendations
- Conclusions

After I have done the presentation, I'll post the slide deck and I may even record an on-demand version for those who are interested. Don't expect a technical talk, or one that goes in great depths: that would be unsuitable for the audience, and I only have 45 minutes (including discussion).

Note taking for CISO's

2010-04-03T13:37:38Z

I have found note taking to by my way of staying at a relatively stable level of sanity.

The first key to successful note taking is that all my notes go into one (Moleskine) book (get them at your local Barnes and Noble stores). It has a hard cover and heavy paper and goes with me wherever I go. Because I have a tendency to capture complex thoughts in diagrams, my choice is the book with blank paper (no lines), but pick what suits your fancy. Each book has 240 pages, which is enough to capture between 6 months and 9 months of my notes.

Colleagues in meetings lovingly refer to it as my little black book (with the DefCon sticker on the front). Because all your notes will be in the book, you'll always have them all.

The second key to successful note taking is to find a good pen. Don't use the $.79 disposable one, but pick one that really is set to your hand. I use Parker Sonnet fountain pens with black ink and a medium-sized nib. Because the Moleskins have heavy paper, the ink doesn't bleed through the pages.

Next, note taking etiquette. Mark every meeting with the title of the meeting (e.g. CIO briefing), the date and a page number (with total page count). Even if you don't take any notes during the meeting, you'll have record of the fact that you attended.

Here are some tips that I have found useful:

Hyphenated list elements: reserved for items I need to bring to the table. For most meetings, I reserve one page ahead of time. While I do other things, I may add list items to the page reserved for that meeting before the agenda actually comes out (if there is one).

Square boxes: reserved for action items I need to follow up on. When the action item has been completed, check it off. Flipping back through the most recent pages of your book will always give you your latest action items that still needs to be addressed.

A typical note page will look something like

-------------------------------------------------------------------------------------------------------------
Managers Status Updates 04/01/2010 1/2

- update: MS OOB
- Vulnerability scan results sucked.
- Firewall is on fire most of the day
- web coding must be improved; XSS are not part of the func. requirements
- please don't hack us next week, as we'll be on vacation

sysadmins: unexpected outage of internet uplink, failover worked

[ ] get details to rule out DoS

desktop grp: antivirus keeps on triggering false positives

[ ] schedule product review and eval alternatives during summer

cio: budget requests approved

[ ] go party
-------------------------------------------------------------------------------------------------------------

Keeping the notes brief and to the point will be enough to trigger your memory, but serves as record of what happened. Labeling them with the date and the title will allow you to quickly find the meeting that you are looking for and the page numbering is just good housekeeping.

Let me know how it played out:)

SOURCE Boston professional development

2010-03-30T14:25:02Z

SOURCE Boston is one of my favorite information security conferences. It is not to say that other conferences are not good, but SOURCE has the benefit of being relatively close by (New York - Boston is not that far), and the conference is not massively large. As a result, there is excellent interaction between the crowd and the speakers, which is something I appreciate a lot.

Unlike last year, I will most likely not be presenting a full talk. Instead, the organizing committee has asked me to design and moderate a workshop on professional development. Of course, I accepted this invitation gladly, and we are now working to design the session.

To get started in the information security field is not easy. As shrdlu put it recently, information security is a highly specialized craft and practitioners need to get their feet wet before they can truly transition into it. The session at SOURCE Boston will be highly interactive. We'll begin with a 15 minute panel session that should set the stage for the remaining time.

The remainder of the time will take the form of a workshop in which we'll discuss topics like setting realistic goals, identifying relevant work opportunities and building a personal network. We'll also talk about what it is like to be a mentor, and what it takes to be successful as one.

We hope to cover an audience that may range from graduation college seniors to individuals who have been established in a professional environment. If you are interested in learning more, or if you have suggestions to make this session even better, please drop me a line and we'll talk.

More information about SOURCE Boston is available on its web site.

Communicating incident response plans

2010-03-15T19:05:12Z

The purpose of having a written incident response plan is to enable an organization to move from being reactionary to (perceived) information security incidents to being well-prepared and able to respond in a way that has been previously determined.

Having a well-defined response plan in place avoids panic, and allows an organization to assess the impact, determine the proper response, and then execute what needs to be done. As a result, response activities will be appropriately scaled and cost-effective as much as possible. It will also ensure that adequate documentation is maintained so that lessons can be learned when the dust has settled.

One activity that an information security manager should never underestimate is the effort that must be deployed to communicate the incident response plan within the stakeholders and obtain buy-in among all those who are affected by it. The plan must be reinforced regularly, either through scheduled reviews and discussion in plenary meetings, or by doing actual drills and exercises.

In an organization that is heavily driven by audit requirements, you probably want to collect some form of sign-off to ensure that all members of your team, as well as key constituents, have read the document and taken note of it.

An incident response plan is only useful if everyone who is affected by it knows about it. Do not fall into the trap of developing a plan and not communicating it. Also avoid the mistake of not developing one all.