Making sense of pen testing, part one

This is the first in a series of posts looking at the current state of pen testing as I see it and presenting some ideas for the future. In this post I will apply a framework to understanding the process of pen testing.

In the next post here I discuss some of the problems I see in pen testing.


The pentesting process is a form of expert behaviour similar to intelligence analysis where there has been a lot of work understanding the key components of expert performance; this is often broken down into a process flow as follows:

Gather Information → Represent in Expert Schema → Develop Insight → Define Product or Action
Read the rest of this entry »

ORGCon 2012

I attended the Open Rights Group Conference (ORGCon) this year.

We are at a weird moment where the Internet and the associated digital technologies it has spawned and supported are wreaking changes to the social, cultural and economic environment that don’t easily fit the current models of law and governance. Cory Doctorow makes this point more completely and more eloquently here (Lockdown: The coming war on general purpose computing).

As a result we are seeing law and regulation that is driven much more by lobby groups rather than politicians. The politicians that understand these changes are few and far between and made more notable for that irrespective of their party allegiance (For example Tom Watson and Francis Maude). I am heartened by the ORG as they represent the other side of the coin from the industry lobby groups.
Read the rest of this entry »

Documenting an As-Is Security Architecture, part two

This is a continuation from part one.

Documenting current environments

This activity is focused on identifying the physical and logical environments in scope for the business architecture.

A logical and physical model will be created to hold entities describing physical facilities, wide area networks and systems that store, process or transmit information assets that fall within scope of the business architecture. It is likely there will be gaps identified and that these will need to be investigated with stakeholders and partners. This is a model that will evolve with more detail as the projects move into delivery and suppliers are contracted and systems are implemented. Read the rest of this entry »

Documenting an As-Is Security Architecture, part one

This is the first of a two part post, part two is available here.

The following list is a set of activities that need to completed at least once to document an existing As-Is security architecture view for a business architecture and then need to be maintained over time through repeat reviews.
Read the rest of this entry »

Security and Systems Engineering

In my experience when a business brings security people into their systems engineering process they are trying to solve a problem. Usually there has either been a painful security incident or some security testing pushed them over the edge and they feel exposed. Sometimes they are undertaking a big enough change or the security implications of a change are so obvious that they realise they need to ensure security is covered off.

However, while the senior management of the business is looking to solve the security problem there is commonly confusion amongst the system engineering teams, the new security team and the middle management of the business about what it is they are asking for and what it is they are getting. Read the rest of this entry »

Twitter RSS