Category: Security Good Practices

In my vast experience of the Agile Methodology (just over a month now), I have managed to go from a proponent (as in Running PCI as an Agile Project?) to someone who is rather more circumspect when the objective in question falls outside the realm of a short-term project. An easily defined short-term project at that.

In other words, NOT a soup-to-nuts security program.

The overused adage; “If all you have is a hammer, everything looks like a nail.” is particularly relevant here, as Agile proponents have actually gone looking for nails to the point where some security ‘professionals’ are designing their entire program around this single tool! Being generous, this shows a spectacular naiveté,  at worst, it shows a complete ignorance of what constitutes a sustainable and effective security program.

And to be clear; Agile is a tool, nothing more. It is not a philosophy, it’s not even a framework, it is used for very specific requirements at very specific times for an easily quantifiable result; like a new user interface, a segmentation project, or even the installation of a centralised logging technology. Where it make absolutely NO sense is the exact place a good security program starts; with the culture.

The implementation of a good security program has always been, and will always be, more art than science, and completely dependent on the prevailing culture, a culture defined by the CEO’s attitude towards it. In other words, trying to implement a security program AND instill a culture at the same time with nothing more than a single tool, is no different from trying to build an entire house with just a hammer. It simply does not work that way.

Also, those focusing on Agile tend to come from a highly technical background and therefore focus on technology over process, which just compounds the problem to the point where any short-term gains will be built on nothing but air (like my sandcastle ‘metaphor’). Technology is critical for the automation of KNOWN-good processes, it can never be the solution in and of itself.

In one of my first blogs I posited that there are only Four Foundation of Security:

  1. Management Buy-In / Culture
  2. Policies & Procedures
  3. Governance
  4. Education & Training

…I would now actually add a fifth; Vision (or perhaps just include it in the first one), as it’s the CEO’s vision for the organisation that will drive the development of an appropriate security program.

Assuming you agree with the Foundations, perhaps you can now see how using Agile for any one of them is utterly meaningless. Implementing two week sprints and daily stand-ups to ask whether or not the CEO has signed-off on the security policy framework, or if all relevant staff have taken their annual awareness training, makes no sense whatsoever.

In the development of a security program, a competent security practitioner at the CSO / CISO level would usually follow these steps (gross oversimplification):

  1. Get the CEO to agree to take an active role in the program’s implementation / socialisation. Get this in writing.
  2. Define the governance framework to get all relevant senior stakeholders to the table. Have the CEO ratify it.
  3. Draft Information Security Policy Framework for the policy committee’s review and approval. Have the CEO sign it.
  4. Distribute the relevant policies to the right people as part of the socialisation and initial training exercise. Have the CEO visibly endorse it.
  5. Implement an ongoing awareness program to solidify the culture changes. Have the CEO evangelise it.

If you can’t even get the first step in place, you needn’t bother with the rest, as no matter what you do your security program will collapse under the weight of indifference.

No tool is going to fix this, certainly not Agile.

A CEO discount is when I offer an organisation a 10% reduction on my consultancy day-rate if they can arrange for a 30 minute, 1-on-1, face-to-face, meeting with the CEO.

Sound like a gimmick? Well, it is partially, I’m trying to run a business, but it’s also extremely beneficial to both sides. Not only that, addresses the most fundamental of all security challenges; management buy-in/support. Continue reading “Why I Offer a ‘CEO Discount’” →

Internal Audit.

It’s right up there with Traffic Wardens, Used Car Salesman, and Lawyers, isn’t it? You get a phone call from Internal Audit (IA) and it feels like you’ve just been sent to the Head Master’s office!

But why? If you have been doing everything right, following appropriate policies and procedures, have ACTUALLY read the Acceptable Use / Code of Conduct, why would this be any different? I mean, even SECURITY winces at IA, and we’re total pariahs ourselves!

This is unfortunate, because like it or not, every department needs someone to provide checks and balances. Someone who can look at everything with a fresh and objective pair of eyes, someone not answerable to YOUR boss so can tell them how it is without repercussions, someone who can suggest changes that you know should happen, but fear / politics prevents you from saying anything.

Take your pick, regardless of how you view IA, they, like InfoSec, are an necessary evil in a world where both the threat and regulatory landscapes are spinning out of control.

Best practice frameworks like ISO 27001 call for Internal Audit by name, and an ever increasing number of regulators are requiring  evidence FROM IA processes so that organizations demonstrate that they are actually complying with their own policies. This should not be a hardship, if your corporate security culture was adequate, this would not be an issue. Look to the senior leadership, it they don’t care, no-one else will.

I have stated over and over again that if you were doing security properly, EVERY compliance regulation on the planet would fall out the back-end (plus or minus some customised reporting). Not one has ever, and likely WILL never go above industry accepted best practices, as no-one is looking for perfection, just risk-reduction enough.

It makes perfect sense to me therefore that you would put a watcher on the watchers. Security have their fingers in almost every business pie, just to make sure that proper security controls are built in from the beginning. Like Legal, security is there to save the business from itself, and done properly, it should NEVER get in the way.

This can lead to a certain complaisance, or blinkered view of the world, IA can provide the necessary perspective to continually test processes that that could potentially stagnate if not seen through an objective lens. And who knows, because IA generally have direct (if dotted line) access senior leadership, there is a very good chance your requests for budget/resources will be looked on favorably if supported by an entity mostly immune from repercussions.

In this context therefore, Internal Audit is the conscience of Security; Are the controls enough?; Are they too much?; Are they easily measured?; are they flexible enough to adapt to business goals?; etc…

From the very first policy draft, to the almost ubiquitous Plan, Do, Check, Act of ISO 2700X, security professionals need to look to IA for support and guidance, but the opposite is equally true. IA can tend to rely on their unassailable positions to hide behind lack of expertise in security subject matter, they need to work just as closely with security to make sure they are up to the task.

In all my years performing security assessments, and even providing my own policy and procedure service, somehow I have completely missed out on HOW to actually manage the polices, standards and procedures. Yet I have harped on about them incessantly.

Yes, I have mention a Document Management System (DMS) as a way of controlling and distributing documents, but I had never really given thought as to how you would go about maintaining a library of documents that almost all organisation collect over time.

It may not sound like an important subject, until you realise that no policy, standard, or procedure means anything unless it’s the RIGHT one. Is the procedure you’re working from the latest version? Are you in violation of a policy that can lead to you getting fired because you’re looking at a printed copy from 2014? Are you holding your vendors accountable to SLAs in the latest contract?

The first thing I have noticed is that it’s incredible easy to over-complicate the whole thing to the point it’s unsustainable. It must be intuitive for anyone to follow, and it must be easy to manage, or like everything else in security, it will be bypassed.

I would love to hear from true expert on how this is done, but for now, he is what I think is best:

  1. Document Numbering: Have enough information that you know at a glance what the document is, but not so much that it’s 100 characters long. For example;

    * First 2 characters is the company name, or a designation of external (e.g. CN, or EX)
    * Second 2 characters is the document type (e.g. PO = Policy, PR = Procedure etc.)
    * Third 2 characters is the applicable region (e.g. GL = Global, GB = United Kingdom, etc.)
    * Fourth 2 characters is the applicable department (e.g. XX = All departments, LG = Legal, SE = Security etc.)
    * Last 4 characters is the unique number (e.g. 0000 – 9999)

  2. Revision Number:  rX.0 for major release, and rX.1 for a minor release. So the first draft would be r1.0, a slight change would be r1.1, and a complete rewrite would be r2.0 and so on.
  3. Friendly Name: What’s the document title? e.g. “Access Control Policy”
  4. Document Status: One of only 3 things; DRAFT, RELEASED, or OBSOLETE, all self-explanatory

So, for Acme Rockets Ltd., a first draft of a global legal policy on access control would be; ‘AR-PO-GL-LE-0001-r0.1 – Access Control Policy-DRAFT‘, or a rewrite of a vendor contract related to  a firewall managed service procedure specific to the UK would be; ‘EX-PR-GB-SE-0003-r2.0 – Firewall Managed Service Procedure-RELEASED‘

Assuming I haven’t completely lost you, the next step is to work out how to get them into a centralised and access controlled library to which EVERYONE who needs access, has it. Every RELEASED version of the entire policy and procedure set needs to be online and the location of it familiar to the entire company. No printed version can ever be trusted unless the number, name, and status matches (these should be printed in the document header).

Finally, and here’s the real kicker; EVERY document in use in the organisation needs to be entered into a Master Documents Record (MDR) of some sort, and maintained to an extremely high degree of integrity. In theory you could use your Intranet or SharePoint for the central location and an Excel spreadsheet for your MDR, but best of luck keeping that up to date in a large org.

So, am I, David Froud, actually suggesting that larger organisations buy technology to solve a business problem despite my constant warnings not to do so?

Yes, yes I am.

In 16 years of information security consulting, I never worked at an organisation where ownership of any aspect of the IT function was in the right place, let alone IT Security.

Anyone who has ever worked in IT, regardless of the discipline, knows that the business side of the organisation cares nothing for HOW things are done, they only care that they GET done. Ever try talking to a salesperson about total cost of ownership for their bright ideas on driving revenue?

To be fair, the salespeople don’t have to care, but someone from that side of the business sure as Hell does. Even a £1,000,000 deal is pointless if it costs £2,000,000 to deliver it. Both the business side and the IT side have failed if they cannot easily determine the suitability of the deal. However, it’s the business side that is responsible to justify a project, not IT, not IT Security, the business side.

THEY own it.

Luckily, the steps for getting this information together in the right format are, quite literally, centuries old:

  1. Perform a Risk Assessment (RA) – As boring as this sounds, ANY change to an organisation, even one that seems like a no-brainer, presents risk. Keep it simple, and brief, but without an understanding of the risk, there’s no context for the reward. Selling your only bottle of water for £1,000.00 is a great deal …unless you’re in the middle of a desert.
    o
  2. Perform a Business Impact Analysis (BIA) – This is often seen as a negative thing, where you are spelling out the cost if something bad happens. There’s no reason that positives cannot be built in, and often this is entirely appropriate. If the risk determined above, and the cost of bad things happening, is far outweighed by the benefits, then the decision to proceed, or not, becomes much easier to make.
    o
  3. Develop a Project Plan – This one rarely get done properly, but without it, the true cost of a proposed project cannot be determined. The plan needs to spell out everything that is required, including resource and capital costs, and time-frame. Done properly, this will develop into little more than a list of every action item, assigned to individuals, with due dates.

IT and IT Security will be very much involved in this process, so could many other departments depending on the project in question. Legal may be involved from a contractual or regulatory perspective, HR may jump in if they are organised enough have employee skill-set mappings, marketing will certainly want the heads-up if they are to be called on later and so on.

This is why the best companies have three things; a) a robust Project Management function, and 2) a standardised process for requesting project resources, and 3) a centralised Governance function that brings all of an organisation’s decision makers together in one room.

From the RA and BIA you know the cost of doing and NOT doing something in terms of both bad things happening, and potential lost revenue. From the project plan you know what it will take to proceed. The project management function will be able to tell you everything missing from the end goal, and how to get there, and the Governance function will then have everything they need to make EDUCATED recommendations to the executive leadership regarding investment.

This is why IT and IT Security can never OWN anything, they are there to enable, not run the business.