Archive for April, 2011

Infosec London, BsidesLondon & DC4420 – A busy few days

This week I dived back into the UK security industry outside my current little security silo to see what people were up to and see what I’d missed.

I made it to Infosecurity Europe 2011 on Tuesday afternoon. Infosec is a vendor exhibition, they’ve tagged on a set of lectures but they are basically vendor pitches in more of an infomercial style than on the exhibition floor. I loathe the experience on the exhibition floor at Infosec, the rampant commercialism and the lack of detail makes it a terrible place to learn anything new. It is however a great place to waste time talking to bug vendor sales people who know less about their products than you do and spend an afternoon ducking the slightly desperate gaze of the small vendors and professional service firms in the various ghettos in the rear corners.

That said I met a lot of good guys I hadn’t seen for months or years wandering around the corridors, Infosec does draw everyone out into the daylight and the coffee is a lot better than it used to be. The move the Earls Court has made it a lot more convenient and the local pubs are comfortable so it’s not wasted time. Someone is going to come up with a killer app for real world exhibition networking, finding who of your friends and colleagues are there when you are and where in the hall they are or which pub they are in that is going to shift the whole emphasis of exhibitions like Infosec.

I probably will stick to my schedule of every other year for Infosec in the meantime.

Wednesday I headed over to BsidesLondon, a new free security conference in London. It was in a great venue and I was a little blown away by the amount of new young security talent in the room, also surprised and heartened by the large number of Unconvention attendees lurking around the crowd. They opened with the statement there were’nt any security conferences in the UK, I think every Unconner I met told me about that 🙂 The content of the con was okay but I’m not at all sure I learnt anything new.

  • David Rooks talk on using risk as a way of communicating to the business about technical security flaws was as worthy as the subject’s been since 2000, good content but little that was new.
  • Chris Wysopal stood up for Veracode and told us how to translate security flaws into dollar estimates of risk. I really liked  his approach, I also now that if I was presented it as a client I if I wanted I could use the chained assumptions to undermine the argument which makes it pretty much state of the art these days, useful way of talking to the C*O but dangerous around security professionals with different commercial agendas. I was especially taken with his use of the dollar value of risk from other areas such as legal, compliance and the rest that are effectively competing for the controls budget with security. If we could aim for a set of metrics that not only tell us a dollar value for security risk held and legal risk held and compliance risk held but also the cost per $100 of risk to manage in those different areas then we might see security’s big problem. I’m pretty sure (In an unprovable hand-wavy sense) that  managing $100 of technical security risk costs a lot more than managing $100 of legal risk or compliance risk.
  • Stephen Bonner did a particularly entertaining talk on recruitment failures in Infosec, that man knows how to work a room 🙂
  • Steve Lord did a great if somewhat self-regarding talk on the life-cycle of the penetration tester through their career. I suspect it was a talk on Steve’s career as a pen tester but there were enough resonances there for the old crowd in the audience to chuckle all the way through

I like BsidesLondon and I would recommend it to new pen testers getting started and I think as it develops it will find a ‘house style’ but at the moment it was entertaining rather than enlightening. It was run incredibly well and has set a bar for future Uncons to do better. Hey if they can do it surely we can too 🙂

Wednesday night was Alien8s DC4420 for the month, it was a huge meet due to being in Infosec week but was full of a good crowd. DC4420 has interesting talks, Mu-bs slightly political take on sat card sharing was my highlight but is mainly a social event and a good time was had by all. I must make an effort to get 4420 more often.

All in all the UK tech security scene seems healthy, some new companies starting up to fill the spaces left by the recent acquisitions, good people still contributing good content. I’m definitely part of the ‘old guard’ now and that’s probably exactly right.



User-Sourced Security Monitoring

One of the constant challenges I face delivering big systems is meeting the protective monitoring requirements.

A lot of the requirement to spot technical events (low level network probing, back door installation, beaconing and command and control channels) can be covered with a bundle of vendor products integrated into a correlation engine that is tuned by an analyst and watched by expensive security operations staff. That isn’t easy, and getting the buy-in for the capital and operational investment definitely isn’t easy. However it is significantly easier than building a protective monitoring capability that understands the business transactions flowing through a system, significantly easier than finding an analyst who has the skills and time to understand the business rules for those transactions and what the indicators that those business rules have been breached are.

It occurs to me that we have a ready supply of staff on our internal or B2B transactional systems who understand the business context of the transactions intimately….the users!

We have staff in open plan offices, we give them ID badges to wear and ask them to challenge people they don’t recognise for ID. When these staff see something suspicious happening in their work areas they tell us. We put guards on the front door to limit the flow of unknown people into the office, we build secure physical perimeters and monitor them with guard patrols and CCTV. Generally we don’t do this in the offices themselves, we rely on the staff themselves to monitor the inside of our offices for security. This works because they can see what is going on, they can identify co-workers and they know from experience how their business processes work around them. Why not add this visibility and reporting capability to our big transactional systems?

If you’re in a particular team and you could see what your colleagues are doing on the system while you are working on it there is a good chance you would spot something unusual. Such as working a task assigned to a different team member, such as being logged on while home ill, such as making transactions at a much higher rate than the business process usually allows for, such as a user performing a transaction that the rest of the team have never heard of before or is usually working in a different team.

I suggest that for each transaction a short (A familiar 140 character limit perhaps) description is shown in a river of events at the side  of the screen, including a user photo, a user name, what transaction type is being performed, on what data, when it was performed and where the connection to the system came from. Next to each transaction put a ‘Looks suspicious’ button that when pressed sends an alert to the security operations staff to investigate.

The alert can be automatically enriched by the protective monitoring software to include more details about the suspicious transaction, the user that initiated it and the user that indicated it was suspcisious. Such alerts could be weighted by the analyst on the criticality of the transaction and on the relative histories of both the transaction user and the alert initiator. Do either of those users have risk indicators visible in their past behaviour?

This outsources the task of identifying what might be interesting to review out to the users who have the knowledge of what normal looks like.

As long as the private data in the transaction is protected then there is no real privacy difference between this and working in an open plan office.


6 Questions about security the board care about

Another short post to break up the big essays I tend to write.

These are the questions any Security Manager worth his salt needs to have prepared answers for anytime he attends the board of the company or socialises with board members:

  1. Are we safe ?
  2. Can I take responsibility for the actions of the company ?
  3. Who handles our data ?
  4. Who are we doing business with ?
  5. Are they accountable ?
  6. What is everyone else in our sector doing ?

If you focus your metrics away from the numbers of technical security events and away from the numbers of deployed security controls and towards answering those questions you’ll get a much more engaged board who will be happier to hear you speak.

Top 10 Points – Security Elevator Advice

These are my top 10 key points to give to the top man when he asks you “what should we be doing in security?” and you only have a minute or two or you need a single slide on security for the CTO:

  1. Identify and understand your threats
  2. Reduce your attack surface
  3. Compartmentalise your important services
  4. Track assets and fix known vulnerabilities
  5. Teach people to write secure code
  6. Teach people to behave responsibly
  7. Audit these processes regularly
  8. Monitor for & detect intrusions
  9. Prepare for incident response
  10. Choose and measure security outcomes

The challenge  is, there is a large volume of material needed to understand what they mean and why they matter and years of experience needed to truly understand how to deliver them.

Security Debt

The following are some notes I put together describing the concept of ‘security debt’ as a way of thinking about managing security in a real world business, its taken on some new meaning following the credit crunch….

I think there are extensions to be made to the concept but I am interested in any opinions on the idea as an approach.


Debt is a useful tool for maintaining the ebb and flow of cash flow over the short term. Technical Debt is a metaphor coined by Ward Cunningham in 1992 to describe the short-cuts in software development that end up costing more in time to fix and reduced flexibility in the future.

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.” Ward Cunningham, The Wycash Portfolio Management System, 1992.

The concept of Technical Debt has become a useful tool in software development, especially in recent Agile Development methodologies. The concept of debt, trading future cost against today’s benefit, can be usefully applied to the management of security in large organisations.

Security Debt as a concept describes the gap between the Security Target for an organisation and the security implementation that is delivered. This debt represents a risk above and beyond the Risk Appetite, as well as the savings of cost and/or time in the delivery of the business need.

Risk Appetite

The Risk Appetite is the amount of risk the organisation is content to accept in the normal operation of its business. The Risk Appetite for an organisation is set and owned by the management board. The Security Manager can ask a series of simple questions of the board that he can use to document the Risk Appetite in the security context. These questions include:

  • Do you want full compliance or risk-based compliance?
  • Do you want to meet independent standards?
  • Do you want to certify to independent standards?
  • Do you want to be more secure than your competitors?
  • Do you want to be no less secure than your competitors?
  • Do you want to take more risk than your competitors?

Security Target

The Security Target is the standard of security in different environments that the organisation deems to meet the risk appetite. Using the answers to the Risk Appetite questions a competent Security Manager should be able to establish a security target that would meet the Risk Appetite identified by the board.

The Security Manager is responsible for ensuring the stated Risk Appetite is reflected in the operations of the business though the implementation of the Security Target. The Security Manager *OWNS* the job of interpreting the Risk Appetite into the Security Target. The Security Target is characterised by its maturity as follows:

  • Level 0 – There is no clear view of security target.
  • Level 1 – The description of the Security Target relies on opinion or experience of security team on a case by case basis.
  • Level 2 – Some documented security standards that meet the requirements of the Security Target exist.
  • Level 3 – The complete Security Target based in documented standards exists.
  • Level 4 – The complete Security Target exists and the organisation has demonstrated processes to review and update the security target in line with changes to the Risk Appetite or changes to the environments on a regular basis.

The Security Manager is responsible for improving the maturity of the Security Target from level 0 to 5.

Security Debts

When a conflict occurs with the business over the level of security controls required by the security target in any particular implementation there are two possible outcomes:

Where the risk is deemed high enough by the Security Manager then it is escalated to the board for resolution. This is expected to be a very rare occurrence.

Where the business owner of a legacy asset or a business sponsor of a change project wishes to take increased risk it is documented as a “Security Debt”.

The Security Debt is documented in a standard format and contains a brief description of the issue at hand, a statement from the Security Manager on the perceived risk level and a quote from the business owner/sponsor of the cost and/or time taking the risk saves versus full treatment. It is signed by the business owner/sponsor.

The perceived risks are identified by the Security Manager roughly as one of the following based on the level of divergence from the Security Target in the particular environment in question (More trusted environments can diverge further for less debt):

  • Critical (Black)
  • High (Red)
  • Medium (Orange)
  • Low (Amber)

Critical or Black risks are escalated to the Board. There are no green risks in security 🙂

Security Debt Management

The Security Manager is responsible for reporting monthly to the board on a headline total security debt or Organisational Security Deficit and is responsible for reporting bi-annually on a detailed breakdown of the Organisational Security Deficit listing numbers of & levels of risks by business owner/sponsor and the total cost and time savings by business owner/sponsor.

Paying Down the Debt

Decommissioned systems or assets with outstanding debts have those debts cancelled. The Security Manager will provide business cases for large scale organisational security improvement programmes and the development of central security services that should focus on potential reduction of the Organisational Security Deficit or on future Security Debt prevention.


Twitter RSS