Author: David Froud

Once again, my ability to help out with this stuff is limited, but even my knowledge of what constitutes a good coding practice exceeds that of most organisations with whom I’ve worked.

The best phrase I’ve heard about the need for security relevant skills in coding is; “Applications are the gateways to your data.” So no matter how much network security you have, no matter how many controls you have in place, if your applications are insecure the bad guys get what they are after.

Functionality, and sometimes just appearances, often wins over the needs to build in security from the ground up. This is especially true with organisations who do not have the necessary skill-set in-house and are forced to outsource. The inability to conduct the right due diligence, as well as the usual budget constraints, combine to perpetuate the same vulnerabilities for quite literally decades.

Cross-Site Scripting (XSS) for example, has remained in the OWASP Top 10 since its first release back in 2004 (according to this site anyway), and has never dropped below 4th. How is that possible? With the enormous amount of information out there about how to code against this flaw, the answer is not that the bad guys are getting smarter (which they are), it’s that we are staying ignorant.

Ignorance is a choice.

As much as spending money on security is the last resort (in my opinion), few organisations have the luxury of maintaining a secure coding skill-sets in-house, meaning this must be outsourced. This is simple for web-hosting, just find a compliant provider for the services, custom apps however require a little more due diligence. Luckily all you have to do is ask the right questions. Oh, wait…

In a perfect world, your security needs would drive your budget, in reality, your budget determines what quality of service you can afford. To once again quote the cliche; You get what you pay for. Unfortunately, the competition in this field is so fierce, that organisation are almost forced to provide a crap service just to break even. It used to be that security testing involved a human being skilled in the arts of ethical hacking, now price compression is pushing everyone down the road of automation and good-enough-for-PCI-work.

So regardless of which development life cycle forms the foundation of your coding practices, it must include security at all stages. Let’s take the waterfall method as an example;

waterfall

 

Security is built into no less than FIVE separate phases; Requirements, Design, Development, Testing and Monitoring, and this is in no way overboard.  Spiral, RAD, and Agile are no different, it’s just effected slightly differently.

In the end your WRITTEN life cycle must be taught to all parties, and followed explicitly, and strict separation of duties put in to place. This is not to say that you now need to hire ten more developers to meet the intent, but your checks and balances between the FUNCTIONS of the process need to show due care and attention.

Again, I’m no expert in this stuff, and there is really no way of going above and beyond here (not that going too far has EVER been an issue I’ve come across), but there is simply too much information out there, and too many talented security professionals, for there to be any excuses for not building appropriate security into your development life cycle.

Oh, and if you don’t use a code builder software (GitHub for example) to enforce the appropriate phases and authorisations, as well as effect the separation of test and production, you are already way behind the curve.

Finally, if all you use is the OWASP Top 10 as a checklist to test your web facing apps, you will be breached, it’s just a matter of time.

Not sure how to proceed? Ask.

By the time you reach your 40’s, there’s a very good chance that you have lost a job or two (or four, [cough]), either by redundancy, pressure to quit, or being out-and-out fired.

If it happens once, you can chalk it up to being one of those things. If it happens again for the same reason, then you really need to start taking note. A third time, and you are clearly in a pattern of your own making. Yes, your making, and it does not matter for what reason you lost your job.

This does not necessarily mean that you are a bad person, or a screw-up, and perhaps you were actually in the right when you were ‘let go’, but the fact remains that you are the one out of a job. Unfortunately most of us keep going back to the same pattern, and I can assure you, you will eventually run out of decent options.

Hopefully if you find yourself in the above scenario, you are now prepared for a little self reflection. WHY do you keep imploding at work? What is it that YOU keep doing that makes your unique talents and skills so easily replaceable? There are basically two negative extremes here:

  1. You are completely deluded as to what your strengths / talents actually are; and
    o
  2. You are actually a jerk.

If you’re a nice person in a position to do what you do best every day, would you really have been ‘laid off’ from an organisation that’s still in business?

The issue is that most of us are not always nice, and for more reasons that anyone would ever care to know about, we are probably also not doing what we love to do. Quite frankly, most of us are not even doing the things we’re good at, let alone love. For every kid who knows at the age of six that they want to be a doctor, there’s a hundred kids with no clue.  That cluelessness can last a lifetime, but life goes on and you have to do something.

What happens to most of us is that we bounce from one thing to the next, and by more luck than judgement, we find something tolerable. But instead of using the steady income as a springboard to what’s next, we hold out for the perfect job, the perfect title, or a passion. The perfect role does not exist, not if it comes with a title. No job description I’ve ever seen is based on my skill-set or talents, it’s based on what the company I work for thinks they need.

Fair enough you might say, they’re the one’s paying you a wage, but it’s completely self defeating in my opinion. It puts us in a position where we have to balance the good with the bad, which can only ever be frustrating to the point where we start to focus on the bad. Once on this downward spiral it is very difficult to stop, and we may find ourselves in a position where our job is at risk. Whether we know it at the time or not.

We have always had a choice, this scenario has always been of OUR making, but hindsight is not going to help here unless it’s in the form of self reflection, and lessons learned. So what DO we do now? Leave for another company before we get fired and start the same pattern all over again? Start your own business because we’re basically unemployable?

Or, are you going to do what you should have done years ago?; take a long hard look at yourself. Wherever you are in your career, you MUST ask yourself every day whether or not you are doing something sustainable. If you are going home exhausted from frustration each night, or are constantly complaining about something, there’s a very good chance you are in the wrong place and will wind up having to make a difficult decision.

Or that decision is made for you.

Forget the company you work for (unless you hate their ethics / values), and forget your title (it’s limiting), are you mostly doing what you are best at and maybe even enjoy? If the answer is yes, then by all means defend your job if threatened, if the answer is no, you should probably see it as a wake-up call.

[If you liked this article, please share! Want more like it, subscribe!]

This may be the 12th post in my series, but I cannot stress the importance of good change control enough. I have said [too] many times that maintaining a good security posture is difficult enough, but to make things easier for bad guys from the INSIDE is just plain dumb.

If nothing in your environment changes, the only way risk can increase is by a change in the external threat landscape. Your Vulnerability Management processes should have this mostly covered.

Like almost every other process in security, change control should start with robust policy and procedure, and a well designed and up-to-date, Asset Management system. If you have not only a complete listing of your physical assets, but your business processes, data stores, system and data ownership, personnel & skill-sets, regulatory dependencies, and system criticality mapped out, you have the foundation for very effective change management. Difficult to create?; yes, difficult to maintain?; only if you don’t do it properly.

Speaking of change management, if you don’t have a change control board, get one. It does not matter what you call it, but it should contain enough of the right people to ensure that both the IT and the business side of the organisation can have full insight into the risk management process, and the upcoming changes to the environment, AND to make sure these changes are in-line with the business’s goals.

Good change control starts with a policy, is clearly explained in procedures, and is central to ANY changes that can affect the continued security of your information assets. From patching, to firewall rules, to application upgrades, to server on-boarding, everything must be reviewed and approved by the APPROPRIATE level of authorisation channel. Change control can never be seen as a bottle-neck or it will be bypassed, so unless you are able to rank your changes into distinct approval channels you will end up doing too much, or too little, neither of which is sustainable.

As far as PCI is concerned, you could email your change requests to whomever is responsible, and maintain the list on a spreadsheet. For small organisations this may be appropriate, but of all things to put online, standardise, and at least partial automate, change control is way up at the top of the list. Right next to your Asset Management System itself in fact. Or even better, PART of it!

Here’s how I think Change Control should be done;

  1. The ‘Paperwork’: You will need a –

 i.   Change Control Policy – Keep it simple, even something like; “All changes to IT systems (including, but not limited platforms, application, and data) will be subject to an appropriate review and approval process as determined by the highest data classification.”, is better than most organisations have in place.

ii.  Data Classification Policy – Without a data classification policy there is no way to determine the correct level of review and authorisation required. Patching will not go to your review board, but major application upgrades certainly will. Only appropriate processes are sustainable.

iii. Change Control Procedure – Specific and easy to follow instructions enabling EVERYONE in the organisation to request a change in a uniform manner.

  1. Change Control Board – It does not matter what you call this, Change Control Board (CCB), Change Advisory Board (CAB) or Rumpelstiltskin, the charter is the same; Bring to bear all relevant resources from the business and IT sides (and SMEs if appropriate) to review and approve all changes that meet the established criteria. This should include relevant system / data / process owners where appropriate.
    o
  2. Integrated Asset Management System (AMS) – Without an integrated AMS you lose the ability to add a second layer of criticality rating to your change requests (Data Classification being your first). A proper entry into the asset register will include process dependencies, regulatory implications, max. data classification, and a system ‘importance’ rank. When these assets are available to the change control requester as a drop-down list, the full impact of the requested change is immediately apparent, and the correct level of review and approval automatically assigned. If each asset also had the system / data / process owners assigned, the review board can be built and perhaps even alerted automatically.
    o
  3. Change Closure Checklist – Too often changes are closed before the correct testing is performed, but again, what testing and approval is appropriate should be tied to the importance of the change. Vulnerability scan results, penetration testing results, user testing input, and so on are just a sample of the things that could / should be done before any change is closed.
    o
  4. Periodic Review Against Management Metrics – The change was made for the benefit of the business in some fashion, right? How do you measure success? The answer of course is; “That depends.”, but a specific date / time should be set to review the changes made to ensure that all success criteria are met. This should not be complicated or labour intensive, ever, but the review process is the only way to feed back efficiency improvements into the risk management process. Nothing is perfect.

The above list assumes you have included the basic information required to request a change (Documentation of Impact, Back-Out Procedures etc.), but the PCI minimums are rarely sufficient for an organisation that really cares about this stuff. Again, you don’t want the request process to be ridiculously long or complex, but if you don’t provide enough information up-front, you cannot perform the correct review process, nor can you measure success of the results.

Finally, if your change control process is not owned by your Governance function, you will never be able to bring the correct business oversight to bear. IT and IT Security are only ever enablers, it’s the business side that needs to own the goals.

Another crazy long blog, apologies, but change control is just that important.

I read a rather long but very interesting article the other day (thank you nephew) titled ‘The Coming Digital Anarchy‘ by Matthew Sparkes (Telegraph). Despite the rather dramatic title (I have done this egregiously myself from time to time), the concept regarding the future of ‘blockchains’ is sound, and is a far better researched and a far more encompassing version of my earlier article ‘On The Irrelevance of Money‘.

However, with the exception of one fairly cryptic phrase; “In [his] version of the future, identity and reputation will be the new currency.” the means by which this new order will be usable has not been addressed. Nor have I seen it addressed in any other articles of its ilk.

Regardless of the manner in which our data is stored, either the current file/database method, or the de-centralised / distributed method of blockchains (written for the crypto currency Bitcoin, but has much wider implications), we, the owners of the data, need to access its function securely, and put it to use in any scenario we choose.

If you can assume for the sake of argument, that the concept of the block chain is a valid method of storing and securing data, how can we access the data’s benefits in a method that’s equally secure? Your computer, mobile phone, static knowledge (username / password etc.), physical tokens (credit cards, RSA Tokens) are what we use now, and seeing as they are based on current methods of authentication, inherit their flaws. It is a hard enough stretch to get people to accept that their entire ‘Internet Worth’ (trying to coin this phrase) is not maintained by any institution, but to grant access to this without ensuring your identity is protected in the same way goes too far, even for me.

Your identity is all you have that’s truly yours, everything else is a universally agreed representation of value (money for example), so until such times as we can bring our full identity to bear we are reliant on small, and very specific elements of it. Elements that are relatively easy to steal, and duplicate.

It follows therefore, that the more of our identity were can securely distribute, the harder it will be for anyone to pretend they are us. Even in a scenario like Invasion of the Body Snatchers where they completely take over our physical bodies, unless the entirely of my life was instantly at the impostor’s disposal, AND they were able to duplicate my personality precisely, my family and friends would know there was something wrong. And if I’m honest, might actually prefer the new me.

Which brings me to the true value of your identity; Trust. You would not lend a stranger a £1,000 without significant rules in place, but you would think nothing of lending it a family member (assuming they’re not a douche-bag). Why? Because you have a lifetime of trust built up behind you.

How then do we duplicate a lifetime of trust in an electronic form, between two complete strangers? Well, if you’re reading this YOU can’t, probably it’s too late for most of us, but it’s NOT too late for those young enough to begin the process. All we need is the technology.

Oddly enough, I think that block chains provide the answer here too, but I am making a huge assumption based on limited knowledge of how they work. However, from what I know already, they are an ideal medium as their very nature is to record everything that ever happens from the beginning. It just needs to be worked out how to accept the input from everyone with whom the individual comes into contact, and how to represent that in terms of levels of trust. Much like a credit rating, but infinitely more difficult to explain.

In just the last few days Ghash has thrown a huge spanner in the works by controlling the magic ‘51%’ of Bitcoin, thus completely ruining the whole concept of de-centralisation. They have said that we should not worry, and to trust them, but so do the banks. There is clearly a lot of work left to be done.

Until people MUCH smarter than me can work out these issues, and we completely redefine the concept of Privacy (that’s the easy part, right?), this is all theory and speculation, but I cannot see any safer way to get where we are headed. Things change, whether we are ready or not.

Your identity as a baseline is both irrefutable, and cannot be duplicated, but it DOES mean you have to be a decent citizen your whole life or be ostracised. Is that such a bad thing if we have a global consensus on right and wrong?

[If you liked this article, please share! Want more like it, subscribe!]

For those of you errr… fortunate enough to be have been performing PCI assessments as long as I have, you will have noticed the ‘progress’ the DSS has made in terms of turning ‘just patching’ into more of a risk based approach to threats. Yes, it’s about time, and no, it has not gone far enough to be truly effective, but it should go to show just how important this subject is.

v1.1 of the DSS didn’t contain the phrase ‘risk-based’ at all, v1.2 and v2.0 say that organisations “MAY consider applying a risk-based approach to prioritise their patch installations.”, then finally in v3.0 says; “6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.”

This only took 8 years.

Unfortunately, it’ll be 3 more years before they can make any additional improvements, and when you consider how far they are already behind, and the rapidly worsening threat landscape, you simply cannot afford to do the PCI minimums here.

Vulnerability Management is the overarching process whereby a significant number of other processes are combined into a method for the never-ending examination and remediation of threats to your business. Everything from risk assessment, to asset management, to configuration standards, to change control, to patching, to vulnerability scanning to penetration testing, to monitoring and incident response, all combine into a life cycle of knowing your business goals, and enabling both IT and the business side to get there safely.

REAL Governance in other words.

I have already explained [hopefully] why Risk Assessment s and Asset Management are the starting points for a proper vulnerability management program. The rest of my list below will get their own post in due course, but here’s why they are included here:

  1. Configuration Standards – No point trying to manage risk on something that is fundamentally flawed. Don’t get these right and all the vulnerability scanning and penetration testing in the world isn’t going to help. Not to mention your logging and monitoring would be so inundated with false positives as to be rendered ineffective;
    o
  2. Change Control – Without VERY robust change control even the best initial set-ups can become rapidly insecure. Why make things easier for the bad guys?;
    o
  3. Patching – For the longest time the PCI DSS focused on the patching of systems, and insisted that all relevant, critical security patches be installed within 30 days. This completely missed the point, and while patching is an important aspect of vulnerability management, relying on reactive security measures is like taking aspirin for a broken leg;
    o
  4. Vulnerability Scanning & Penetration Testing – I lump these two together not because they are so similar (they aren’t), but because they are complimentary and fall within the same category; Testing. The cycle of constant improvement cannot be maintained if you aren’t testing your security controls and processes in some way. Test, fix, test again, repeat forever;
    o
  5. Monitoring – For every second of the day, your systems are providing information relevant to their health and security. Ignore these events, or fail to properly interpret these events and you have negated any ability you have to prevent a minor incident from becoming a worse. Unless you are able to baseline a ‘known-good’ environment, you have no idea what ‘bad’ is;
    o
  6. Incident Response (and Disaster Recovery) – In theory, you should never need Disaster Recovery if your Incident Response is as good as it should be. Without all of the above in place, you don’t have the ability to perform either well.

One of the most common complaints I get from clients is that previous QSAs have insisted that relevant, critical security patches are installed within 30 days. Yes, that’s what the PCI DSS says, but the only reason I can see that this should be a problem is if your Vulnerability Management process is so poor that you cannot show your QSA how installation within one month is actually MORE risky than to not.

There can be many reasons for this, but the inability to test patches and/or get them rolled-out in time are not excuses I would accept.

I have yet to see Vulnerability Management done well, in ANY organisation I have assessed. The pro-active life cycle approach to security, while very difficult to set-up, is nevertheless very simple and far cheaper in the long run that a reactive one. My analogy for this is that it will take me a year before I’m fit enough to ever run a marathon again, but if I had just MAINTAINED my fitness from the last one, it would be a hundred times easier.

The only things in security that stay the same are the basic good practices, vulnerability management is one of those basics.

[If you liked this article, please share! Want more like it, subscribe!]