First of what may turn into a series of GRC day job related posts. Here I’m highlighting challenges for anyone involved with system security audits or assessments. This isn’t about merits of various standards, home grown lists of security controls, or system audit tools. This is about the assessment process and management of that process. Things that are affected by chosen benchmarks, but not dictated by them.

Setting The Scene

Some key challenges in running a productive and supportable system security assurance programme:
The biggest and most dangerous elephant in the room is the true complexity of a system risk profile. The matrix relationship between in-scope system interfaces, web servers, application servers, midrange/database layers, the quantity and type of data held there, operating systems, their network context, interconnected systems and the business process context around all that. A perspective more familiar to criminals and good pen testers than the average auditor.
In the world of turn-the-handle assessments (maybe for PCI DSS, SOx, ISO27K, Policy or a.n.other security benchmark) it’s far less cut and dried. It’s a job still often done with Excel spreadsheets. A flat data format for a multi-facetted risk picture (of course a home grown database or GRC tool can overcome that, but only if you understand that context well enough to configure it). Thoroughness can fall victim to time, budget, data availability issues, management issues and a lack of assessor, (or system owner) experience.
People tend to measure success of such efforts in delivery terms. Getting through that list and fixing discovered non-compliances A. S. A. (bonus threatening) P.
Arguably the most damaging and frequent issue is ignorance of (or just ignoring) risk. Not all non-compliances are created equal (far from a cutting edge insight), but many people treat them that way. Systems often don’t get a weighting based on any realistic view of potential exposure and impact of compromise, which in turn scuppers effective prioritisation. It also opens the door to a problem familiar to many of you: System/control pairings having effort beyond all sense thrown at hitting compliance benchmarks. Most regulators and standards assessors leave space for a rationally justified risk acceptance, but you have to have the risk perspective to put a decent one together. If the tick-box letter of compliance law is all that guides you, I guarantee each cycle of effort leaves a persistent subset of stubborn holes that either age ungracefully, or get informally risk accepted.
The work can finally devolve own to a risk-agnostic and politicised numbers game. Misdirected pressure demotivating staff, breaking relationships with the business and producing poor quality results.
So what can one do?

Outsource

Either outsourcing systems, or outsourcing the assessment effort. I wanted to get this out of the way at the start because it’s so frequently the go to place when things have gone badly wrong. All of our forebears who told us not to outsource a problem getting disrespectfully ignored.

I’m not going to dwell on it now. Just remember, you outsource the effort, not the risk. You are duty bound to do hard core due diligence and continually assess your helpers. Comfort yourself they are tackling the aforementioned problems effectively and keeping a secure reign on the huge quantity of confidential data exchanged to facilitate work.
There can be dramatic economies of scale when specialists take the assessment work on, but it’s their saving, not yours. When you’re confident they’re going to do a consistent and adequate job (e.g. not waving experienced staff in front of you, then throwing baby consultants at the actual work), carefully weigh up the cost comparison between doing it better in-house and chucking it over the fence.
So moving on to some of the key things that often get less attention;

Defining, Identifying & Educating Stakeholders

Something equally relevant to DIY assurance and planning then managing outsourced work. Reactively justifying delivery and risk remediation problems to concerned stakeholders rarely goes well. Ditto for pitches for extra budget when the people with the pursestrings had no idea of the effort and complexity involved.
It’s how missed deadlines become more common than hit ones and how credibility gets destroyed. Think about all of your requirements, sponsors, impacted business areas, dependencies, limitations and risks EARLY and get names or roles linked to all of them from day one. Examples for your RACI might be:

• Input to and sign off for the overall approach and key target dates
• Input to and sign off for the system scope and basis for prioritisation.
• Input to and sign off for ‘how much is enough’ in terms of risk reduction and delivery
• Input to and sign off for risk acceptance: A process, RACI, required contents and requirement to review (if there’s nothing fit for purpose already in place)
• Escalation routes for non-compliance related risks
• Escalation routes for delivery related risks
• Dependencies on various teams for data provision, facilitation, risk management etc etc.
• Limitations linked to data availability, data accuracy, tools, resourcing, SME availability, co-operation.

It’s good project management practice, but often half-done if work is just driven by the security function. Very few teams have budget for project managers and hybrids are still thin on the ground.
A key firmly-linked consideration is managing expectations about the amount of up-front effort. It’s almost impossible to backfill goodwill after something has gone wrong, but you can retain it if people were made fully aware of the delivery challenges and risks.

Who Are Your Stakeholders?

As a starter for 10:

• IT System Owners – Those familiar with the existing technology, architecture, configuration, security status and links to other systems.
  
  

  Copyright: rawpixel / 123RF Stock Photo

• Business System Owners – Those familiar with functional requirements, purpose and usage of systems and potential impact on user populations.
• System Data Owners – If that responsibility is not incorporated into one of the above roles.
• Supplier Relationship Managers and Suppliers – A significant proportion of your systems and your controls are probably either supported, developed or hosted by 3rd parties.
• Central IT & Security Service Owners – Going back to my very first point, a significant subset of system controls will be dependent on central services such as build management, software development, access management, patch management, incident management, malware protection, perimeter security, midrange security, operating system security, client side security, data loss prevention, logging, log monitoring etc etc.
• Business Continuity and Disaster Recovery SMEs  – If that is not rolled up into central security functions you will have the same situation with many systems depending on central resilience, backup and recovery controls.
• Operational Risk Contacts
• Executive Owners of Data, System and IT Service Risks

What Do You Do With Your List Of Names?

You send an email to everyone telling them that the work is urgent and they need to drop what they’re doing and help you. Then, when they push back (because they’re working at or beyond capacity), you say: “Hard luck. It has to get done”.
No-one truly believes that’s the right way to go about things, but everyone has been cornered into doing it at some point. It might work once, but you’d better get what you need sharpish. Broken relationships, like broken bones, take a heck of a long time to heal and if not attended to quickly, cause everlasting problems.
Before you ever phone someone to ask questions about a system, you should run targeted and tailored education sessions for key staff in all groups. You share what you’re doing, why you’re doing it (including clarity about the sponsorship you should have confirmed), what you’ll need, when you need it by and what you will be doing with outputs. Then you listen.
Each subset of stakeholders will have other priorities to juggle and other similarly ‘urgent’ requirements they have to resource out of their BAU budget. They will also offer incredibly valuable insights that you need to feed back into finalising and maturing your assessment approach. It’s also a good time to scout for evangelists. There are always pockets of persistent resistance. Evangelists in the same areas are the very best antidote.

---

So that gets you to the starting post in terms of stakeholders and their support. Now how the heck do you scope and triage work so it’s achievable?
If you think that’s back to front and it should have happened long ago, you’d be partly right. Why partly? I’ll explain in the next instalment.