Screen Shot 2016-05-21 at 14.11.05

Agile + Lean + No Vision = ?

In the digital age, the need to transform your business in the face of competition is only going to become more important, and more difficult. Start-ups can build all of this in from the beginning, and have a whole host of success and horror stories from which to choose their inspiration. Large organisations that have developed slowly over time do not have this luxury, but the fear of ‘disruption’ has them mad-scrambling looking for a way forward.

Increasingly, they are turning to Agile and Lean as ways to kickstart their business transformation efforts.

Let me be clear, I have nothing against either of these tools, but that is all they are; tools. They are a means to the end, not the end itself, and over-reliance ON the tools will eventually lead you astray. Unless the business goals drive the tool choice, and NEVER the other around, all the action items in the world won’t get you where you need to be.

This requires a Vision.

And not just one vision, you need a vision per department. There’s no point trying to promote change when your HR department still hires people in exactly the same way, and are looking for the exactly same ‘corporate fit’. What you’ve always had got you here, only something else will get you somewhere different.

IN security for example, an example of a vision statement goes something like; “We will provide world-class defence for all information assets to enable and optimise all corporate goals and exceed client expectations.”

There are millions of these vision STATEMENTS out there, but three things that a lot of organisation who tout them seem to lack are; a) an understanding of what “defence for information assets” actually entails, b) what the most important things are to the foundation of such an effort, and c) the ability to execute that plan at the right level.

For example; Everyone who’s been in security for more than 5 minutes should know that without a policy framework, you have nothing to build your security program on. You then work out very quickly that any policy framework not signed and evangelised from the highest levels of an organisation will be basically ignored. An information security policy framework (ISPF) signed by the CSO is unlikely to followed wholeheartedly by the the other C-levels, an ISPF signed by the CEO will.

Quick Advice: If you’re a security expert, never work for someone who is not prepared to at least ask the CEO to sign something, especially policies, it’s just not worth it.

It is very easy to bandy words like Agile and Lean around, especially if you’re the one doing the delegating, but it’s very difficult to LEAD a team when you yourself either haven’t defined what your vision looks like, or worse, you don’t have one and you simply regurgitate things you’ve just read in a book.

Frantic energy expended on a series of action items [Agile] assigned to a few key people [Lean] is one thing, doing this with a vision of what SHOULD be is quite another.

Screen Shot 2016-05-13 at 00.54.58

Running PCI as an Agile Project?

First, I have only been ‘doing’ Agile stuff for a little over 2 weeks, so this will be less about project management and more about how achieving PCI compliance should be done. Or or this case, could be done …potentially …unless I’m completely off the mark.

Like any project, PCI is just a whole bunch of action items, assigned to an individual, with a due date. That’s it. Unlike frameworks such as ISO 27001, PCI is written down for you, so it makes sense that a methodology like Agile would be well suited to keep a PCI project moving.

The reason that PCI compliance is so difficult for a lot of organisations, is that regardless of the seeming simplicity, determining what those actions ARE, or which to start first, or even knowing when to stop, can be more of an art form that a science. This is why there are so few good QSAs, as they are the ones who are supposed to be providing the guidance on every question you may have, even before you know enough to ask them.

We’ll leave, budget, resources, and having having management who give a crap aside.

So, if you agree that because the DSS is written down for you that you can determine the list of action items required to validate compliance WELL before you begin, then my theory makes a little more sense.

For example; for every operating system you have, the DSS requirements and the actions items are very clear:

  1. Requirement 2: Have a configuration standard, show evidence that your systems follow it
  2. Requirement 5: Have AV, show evidence that it’s running, or have a compensating control
  3. Requirement 6: Document your vulnerability management process, show evidence that your servers are patched accordingly
  4. Requirement 7: Have some form of LDAP, show evidence that access control lists are enforced accordingly
  5. Requirement 8: Extension of Req 7., show authentication and ID management are enforced
  6. Requirement 10: Turn logging on, demonstrate that your SIEM is reacting accordingly, and that all times are synched
  7. Requirement 11: Have FIM, show that’s running

So for an Agile project, you just create a series of issues in the backlog that correspond to the above, and duplicate EVERY issue for all subsequent operating systems in your environment. Simple huh?

And you don’t need a dedicated project manager, just a scrum master who can run all of the daily stand-ups and bi-weekly / monthly sprints. Of course, getting all of the action items right will take a significant PCI expertise, but once this is done for your environment, there’s really no excuse for a stalled project.

The benefits seem to be;

  1. The level of effort required to achieve compliance is obvious very quickly, so resources can be applied in the most efficient manner
  2. Those not pulling their weight become obvious to everyone from the very first sprint, and a determination of anything from individual employee overload to utter incompetence can be determined
  3. You have to think about PCI in the only way that makes sense, and keeps things moving forward; bite-sized chunks of action items
  4. Workloads can be spread around, with current print tasks reassigned to those with more available time
  5. The process becomes repeatable when every action is recorded during the project’s lifecycle.

Anyone who’s ever seen a PCI project drag on for years, or had people on whom you were dependant make excuse after excuse for months on end, something like Agile could be the edge you’re looking for.

Unless I’ve completely missed the point.

Screen Shot 2016-04-25 at 22.32.15

Want to Stay Compliant, Work WITH Internal Audit

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.

Screen Shot 2016-04-22 at 09.50.30

Document Management System, How’d I Miss That!?

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.

Screen Shot 2016-04-13 at 11.44.29

I’m in Information Security, I Don’t OWN Anything!

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.