Observations from VZDBIR 2010

VZDBIR Interesting Graphs

I spent some time today reading the VZDBIR report as many of us did and decided to collate a few interesting graphs from this report. Reports like this are a great way to understand and put some weight behind the argument to the business on actual threats and eventual loss to the business (record %). When collated, the findings provide an interesting view into these threats (whether it be advanced and/or persistent) and what we are dealing with in the security community.


Questions that came to mind following the review 
- How can the compliance world take such findings on board and improve the standards? 
- How can the regulations/requirements improve to put appropriate weight on critical areas in security instead of an across the board 'old school' playing field? 
- Is what is required for compliance enough to protect the business against these threats? (On a second thought, this question isn't worth answering ;))


Certainly, the report shows an ever changing threat landscape. I believe compliance can gain some weight in the security and business world by understanding and incorporating such reports into their standards and requirements.


It is not just in compliance (although it is one of the biggest headaches in the business), but also in Security management that these observations can help teams redesign and re-evaluate their security strategies and invest wisely to address the 'real' threats and improve their ROI.


Thoughts?

Testing and QA Challenges

How much of Testing and QA is enough?

This is a question many executives, senior management, IT managers et. al would be asking themselves.

With the recent failures at Apple and Toyota in this phase of development and/or production, the executives must have surely revisited this and have had discussions on where things can be improved to avoid such mistakes going forward.

Running a successful business is a challenging task. The management always works towards striking the right balance to deliver a product that satisfies the customer demand, ensure that the product is safe and secure and also, that it delivers what is promised. In doing so, the team must ensure right profit margins are maintained to ensure successful running and growth of the business. With increased competition in the market and reduced product shelf life, businesses are facing another challenge - Time to Market (TTM).

I was involved with a public sector organization that faced a vaguely related challenge. This organization managed a big website that went through six week release cycles with new ‘products’ introduced to keep it competitive. With these frequent changes, came struggles to ensure safety and security of the visitors along with delivering the product(s) as promised. Obviously, with short release cycles came shorter Testing and QA windows. Eventually, in such an environment Testing and QA tends to gravitate towards being a checklist than what it is really intended to achieve.

Of course, with the shorter TTM and short Testing/QA durations, there are cost constraints to ensure the business is still viable. Surely, this is an important question - how much of it is enough? With no simple answers, I believe (and you can add to this) the bare minimum that an organisation can do is:

• Effective communications between teams


• Plan well and revise those plans as necessary


• Use skilled staff for Testing and QA (don’t get diverted by an incident!)


• Retest after remediation (this is often missed!)

Certainly, hardware tests should undergo more rigorous and prolonged testing cycles than software products. It is always smart to blame it on software! All one needs is a much awaited 'update'. No product recalls! I bet the next gen Toyota will come with a network port :) Until then, Apple will try and fiddle with the on-screen graphics and ‘set a higher bar’ ;)

Log Management/SIEM 101

I was asked this question by senior management recently - ‘How do we tackle the logging and audit problem?’ Certainly it’s a broad question with no straight answers. The context of the question was to address compliance and incident response strategy.

For organisations with this question, it is a big challenge to begin with, primarily because until recently there was no rigor around this security control to draw from experience. In this post I aim to cover pre-requisites to start the project. 

The pre-requisites:

1. Gather requirements

• If you come across a project team that starts looking at the solutions or technology prior to establishing business requirements, it is doomed to fail.


• Understand the drivers for Log Management, whether it is compliance, operations, incident response, investigations, et al and their specifics. Also, gather requirements from various business functions to gain their support/buy-in.

2. Identify assets (The ‘what to log’ and the ‘why to log’)

• Using the existing asset management program, identify what you want to log. This will also establish whether the business understands the infrastructure that is serving the key business processes. This is the challenging part and more often than not there are only a handful of people in the business who understand and can identify these systems. In worst cases, there isn’t anyone!




• An option to help address this requirement is to look at the latest Business Continuity Plan and identify systems that are business critical and the failure of which will result in the most damage.


• Prepare a draft to group these systems for a phased rollout

3. Create retention and disposal policies

• Once the key systems have been identified for the first phase of the project, discuss within the business data retention and disposal requirements, from both business and compliance perspectives.

In later  posts, I’ll try and cover how to prepare for a phased journey into log management and work towards achieving benefits out of the project.

PCI DSS QSA, ISA and Iron Man 2

Once upon a time, a PCI SSC member sat down watching the Iron Man sequel in cinema called Iron Man 2. Quite impressed by the character Ivan Vanko (played by Mickey Rourke), an idea struck to create a vaguely similar character for the QSA, and name it ISA. Internal employee will go through the PCI SSC ISA training and interpret the standard to create something called the ‘ISA jacket’. At the same time, somewhere in the world or locally, a QSA Company is busy creating a QSA who is working on the ‘QSA jacket’. When being assessed, the internal employee will wear the 'ISA jacket' to protect the assessed environment when QSA comes donning the ‘QSA jacket’. This jacket will also be useful when doing self assessments. There may be sparks when the two jackets meet, but the assessed organisation is intended to benefit. However, this ISA jacket doesn’t come cheap so organisations beware!

New questions will be raised, arguments discussed and hopefully clarified and agreed with the intent to improve the security of the organisations – this is exactly what both jackets were created to achieve, stop the bad guys! Having thought of this again, the ISA seems more of the James Rhodes’ character played by Don Cheadle. Ivan Vanko (use Russian accent from here) is more like the Albert Gonzalez’s of the real world. :)

More ISA info here: https://www.pcisecuritystandards.org/education/isa_training.shtml

Change control, security and PCI DSS

A recent change control question by a colleague, observations over the past year with two clients and PCI DSS related blog coverage prompts me to write this post.

The change control processes followed by the two clients, although implemented and in place could not be more different. One had a mature process with Change Management framework in place with Change Analysts reviewing the requests in the queue, with the awareness necessary to allocate these request on to the right business function for assessment/approval using a relatively mature tool that aided the process. The processes around regular reviews of Changes by key stakeholders were also in place to discuss the requests. The other client had an in-house tool developed to log and track requests. However, the framework on managing the requests was very weak with the Change management team not fully understanding the business and also not aware of who to assign the change to or when to close the request.

PCI DSS covers Change Control related requirements primarily in 6.4 but it seems CC is not given the emphasis that is needed in the security community probably because it is seen more as a service management function. I believe in the below Security Programme Life Cycle diagram and I have come across discussions around this in blog posts quite frequently. Business environments change for various reasons and a good Change Control framework is not only important for agility and adaptiveness of the business but also for the benefit of Security management to maintain the security posture of the environment and in cases improve it too!

SIEM Musings - Part 1

The intent of this post is to provide the reader with the 'Then and Now' view of the SIEM market by using Gartner MQs over the past few years. As the first post of the blog, I also cover how logging and SIEM in general have interested me over these years.

History

It started as an internal project to create a log collection server with one of my previous employers. I was tasked with a challenge to create an easy to deploy, open source and, of course, secure logging solution that essentially acted as a syslog server, within six months. Using Debian LiveCD (Knoppix), SE Linux, VMWare and guidance from @craigbalding, the race against time began to create this extremely light, hardened and secure image that will be used as a cheap and easy syslog server to whoever who wants to deploy one in their business. Obviously, questions came up around what to log, how to log, when to log, why to log etc. Some areas were covered, some were missed and after a many weeks of hard work, the project was delivered. Although it was just a small step in the right direction for the organisation, the biggest benefit for me was the first-hand experience of developing an alpha 'log management' tool and of challenges around acceptance of such a solution in various shapes and sizes of business.

Following this, a project followed to select a mature product that offer the SIEM capabilities. This was in 2006 and I got my hands on, what I believe, the first Gartner SIEM MQ for 1H06.

Since then, I have been studying these reports closely, looking at the developments in the products, deploying some of these products and also working with businesses in various industry sectors to reap benefits from the logging solution of choice.

SIEM MQs

So, below are the MQs from 2006, 2008, 2009 and most recently 2010.

And, below is a quick tabular assessment of the above MQs. This may give an idea on how the vendors have fared over the years in the eyes of Gartner analysts with their definition of SIEM. The vendors in green font have appeared in all 4 MQs, not necessarily in the same quadrant. Pardon the colour selection :).

Hopefully, the above should provide businesses who are in the process of SIEM vendor selection a quick snapshot of where vendors are positioned in the MQ and their journeys within.

Personally, I take MQ as a good starting point for vendor selection/assessment but it certainly shouldn't be the end or focus of it. As most product selection goes, this is a multiobjective optimization problem. Businesses have various constraints to make this selection against like cost, compliance, operations, incident response, audit, etc.

In the next post, I would like to focus on vendor movements in the MQ and whether these movements makes sense. Probably, this may lead to the science behind MQ, who knows!;) What I am really interested to know is whether these movements are actually experienced by the organisations who use these products e.g. someone using Q1Labs since 2006.

Thank you @rockyd for pointing me to 2010 MQ.