Posts Tagged ‘securitymanagement’

Blueprint for Security in 2013

I’ve worked with a number of organisations this year that have been refreshing or redesigning part or all of their security function. It’s brought into focus for me the tension between new security practices and organisational inertia. These have all been organisations that cared greatly about security and were in no way dysfunctional. However, they have all been fighting the battle of five to ten years ago and were only now were undergoing the discovery and self-analysis to understand how to deliver on the aspirations they have in the new context of cyber security and the changed threat landscape.

It has brought home to me the need to focus on continual improvement activities, not limited to finding greater efficiency and effectiveness in what we are doing now but regularly challenging the scope of our activities to see if we need to do more or less or do different things.

(more…)

Business Partner and Supply Chain Cyber Security

I’ve recently been involved in some strategic cyber security work in the UK financial services sector. The financial services sector is a complex and coupled system. While some components are clearly more important there are few components that are inconsequential if they cannot be relied upon. No financial services organisation is independent in what is a highly cooperative sector.

Currently the Information Assurance aspects of reliance on partners and supply chain throughout the sector is handled through third party assurance. Every organisation assesses and is assessed by every other organisation breeding an expensive and distracting industry of rolling security controls assessments.

(more…)

Alignment vs Compliance vs Certification

I have had a series of conversations recently where the concepts of alignment, compliance and certification of ISO 27001 were very confused. Certification was seen as horribly costly and alignment was held out as a good enough goal that was entirely achievable.

In this particular environment they were already ‘aligned’ and had achieved most of what they needed to do to be ‘compliant’ but were still scared of the impact of certification. I ended up having to come to a common set of definitions of alignment, compliance and certification to explain to a variety of security specialists and business stakeholders what they were discussing to try and defuse the fear that was starting to set in. Here are the definitions I ended up with.

(more…)

Security defect triage in delivery projects

The guys at Recx asked me to look at a draft of their recent blog post The Business v Security Bugs – Risk Management of Software Security Vulnerabilities by ISVs where they describe some of the business constraints and influences on security defect triage for Independent Software Vendors and make the case that ultimately the triage decision is a business decision not a technical security decision.

I was happy to do it as I’ve known the guys at Recx for a long time and they are a great little British security company with some seriously deep technical security skills. They have a lot of experience working through ISV security defect triage processes both as external security researchers and as internal product security managers.
(more…)

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.

 

Twitter RSS