Advanced Persistent Threat – risk management by a new name

I am so sick of APT this and APT that. Advanced Persistent Threats, essentially state sponsored intelligence gathering, are no different to the age old espionage between EADS and Boeing – something that CANNOT be prevented by coining yet another new FUD term like APT. Espionage is at least the second oldest profession in the world, and moaning about whatever APT is called this week is not going to change that. If your CFO wants to leak information to a competitor, there is NO information security system ever built that has or can prevent that level of misconduct.

Look behind who is promoting APT this time around. Companies that have IT security services and products to sell. I have worked in that industry for over 12 years now. We have enough work without ambulance chasing as part of our marketing plan.

Remember SOX? Lots of FUD then just like APT today. Lots of “security” (and even non-security) programs designed to bring in so-called SOX compliance – and for what? There were more breaches and losses post SOX compliance than before and its getting worse! Lots of money was wasted on useless programs, and hundreds of millions if not billions of dollars went down the drain for no business return.

If you ever wondered why business folks are rebelling against PCI DSS (which is actually fairly good), fear factor is to blame. We lose respect every time we yell “fire!” when there’s not even a match’s worth of smoke, and when asked for a solution, we want to bring in a DC-10 water bomber. It’s even worse when we come with a reasonable, cost effective, and long term solution and we can’t do it because of the reasonable expectation it’s just another false alarm.

Stop doing it! We have plenty of good reasons to do security (properly), and APT is simply not one of them. If you’re going to yell “APT APT APT!” have the courage to talk about solutions and make them workable, effective, financially responsible, and not to just rabbit on about security theatre solutions to sophomoric movie plot threats. I am not diminishing those organizations like the oil and steel industry who are responding properly where they have a real expectation that industrial or state based espionage will occur or has occurred in the past, but responding to APT for 99% of organizations is just a complete WAFTAM.

I hate APT and all the FUD surrounding it. Scaring the punters is chicken little or crying wolf. Get with the “do something” program. If you’re a news org, instead of talking about folks who got pwned, let’s talk about folks who through good management and effective IT Security programs have survived such “advanced persistent threats”.

What would I suggest we do about APT? Let’s take it back a step – what would I suggest EVERY firm of more than about 10-20 employees should do. Let’s start at the beginning with:

IT Security Management 101

AS/NZS 4360 Standard for Risk Management (1999) and ISO 17799 (now 27000 family) is a great starting point. This stuff is simply not rocket science, any organization no matter what business (charity, big oil, health, military, government, financial, etc) can and should look at what they have today, and start implementing them if they have nothing.

1. ISMS – Create an Information Security Management System. This requires an effective CSO or a CIO who are a force for change with a mandate to take the opportunity cost out of the equation. Spending money on IT security seems a cost for most orgs, but if you see it has an opportunity to do better, you will succeed. Security is a business enabler and indicator of growth. CIO / CSO’s that choose the negative “no” speed hump path simply don’t get it and should be replaced. However, in all cases, it’s important that the CSO or CIO can force business owners to do the right thing or make the business owners accept the responsibilities and risks of poor security decisions. Most orgs do not have an ISMS, and rarely do CIO’s / CSO’s sit on the board or are effective in any fashion. If the CIO / CSO has responsibility and accountability, but no budget and no power to improve things, resign. There’s no way you can effect substantial change when all software is insecure.
2. Create and maintain IT security policies, procedures and allocate (and enforce) responsibilities. Someone has to have the power to say “turn that off”. Someone has to know when it’s time to “turn that off”. Someone should have known before hand that certain systems are more likely to end up in the “turn that off” category and have the power and responsibility to do something about it. The best IT security policy I ever saw* was 10 pages long, had less than 500 words (none of which were “don’t”) and 20+ images in it. Staff knew what they had to do and they did it as it worked with human nature rather than just saying “no” or “don’t do this” or “you’ll get the sack”. If your IT Security policies would make Stalin proud, occupies three massive binders, and is gathering dust in a cupboard, you’re doing it wrong.
3. Create and maintain a global risk register. Start with an Excel spreadsheet if you have to, but most of you should probably go out and acquire one of the many excellent products out there that satisfy the ITIL marketplace.
4. Create a catalog of all your assets (particularly DATA and the systems that handle that data!) and make sure it’s kept up to date. ITIL related products are your friend here – there’s heaps of asset register products out there, but make sure you register data assets as most are all about physical boxes. Assign all assets a classification and make sure folks know how things with that classification are to be dealt with. I prefer a simple three tiered classification system (public, internal, restricted), but whatever floats your boat. 90%+ of all orgs I deal with do not have any idea of what they are running nor the value of their assets or how they should treat them. I know of one org whose HR system was running on a desktop in a cupboard. Unacceptable. But if you don’t know it, you’re negligent, pure and simple.
5. Perform a risk assessment of all assets, particularly critical ones. Risk assessments used to be popular, but I haven’t seen any done for a while now. This is a huge mistake. Put the risk assessments and any findings from reviews in there. Track, assign responsibilities and dates, and …
6. Fix – Assign – Accept. Remediate what you can where it makes sense to do so. This doesn’t mean fix everything, just the things that matter. Insure (risk assign) the truly catastophic outcomes. Accept what’s left.
7. Security is an enabler! Be treated how you’d like to be treated! Train the business folks and developers in secure requirements and coding. Adopt a SDLC and do it. Get and use a defect tracker. Get and use code control. If you’re doing agile, make sure security is a key deliverable of every single user story / sprint / milestone. Make sure your testers test for abuse cases as well as business cases. Think outside the box and think about your customers when you do your security. Security that doesn’t work is wrong. Security theatre is wrong. A multitude of security features doesn’t mean you’re secure. Do security well, and you’ll win because your customers / clients / users will love you and appreciate the efforts you made to make security transparent, easy and effective.
8. Expect to keep up with the Joneses. You don’t need to be bleeding edge, but anyone running Lotus Notes from 2001 or IE 6 should put money aside to deal with the cleanup of any lame attack from the last X years. Just because you’re not paying out on cap ex this year doesn’t make you a good manager. Long term, you’re gonna pay. Even out the expenses and roll out new stuff all the time and retire old stuff all the time. Don’t be afraid to run XP, Vista, Linux, Windows 7, and Macs all side by side. You shouldn’t require everyone to use the same XP image from 2003 on modern hardware – that’s just stupid. Keeping up is the cost of using IT and those who update regularly pay less than those who wait. And wait. And then get attacked. Plant and equipment is tax deductible in most tax regimes, so there’s no excuse not to depreciate and retire old crap. It does mean you’ll need to cope with patching and scalable roll outs of new hardware and software. You need this anyway for those zero days.
9. Get rid of crap that costs a lot to operate. Systems that need patching all the time are doing it wrong. Systems that are attacked all the time because they are insecure should be retired. These systems are not worth supporting. Make the ISVs realize that you only pay for secure software that requires little maintenance. Wean off any supplier who refuses to understand this most basic of requirements. They’ll go out of business, and you’ll save money. Ensure when you buy customized software or have it developed for you that the contract states that the ISV has to fix all security bugs for free and they are responsible for paying for the code reviews and penetration tests to prove that they are secure. That’ll keep the ISVs in line.
10. Monitor and escalate. No system is perfect. Put in procedures to cope with the horse bolting, but try not to have your entire herd and all their tackle gallop out the stables.
11. Don’t be a cowboy – do it all the time. A good ISMS is not a “fire once and you’re done”. You can’t buy a product that does it for you. This is a commitment like GAAP is a commitment to financial standards to use the same systems year in year out. Those that forgot this lesson are now paying for APT. I’m not going to justify why you need to do this stuff, it should be obvious.

This stuff is simply not rocket science. It’s not new. Most well governed orgs already have this in place and have been doing it for a decade or more. The problem is that few orgs are well governed or have any particular driver to do IT Security well. Most CIO’s are untrained in security as they’re often accountants who are brought in to rein in costs – which is a mistake. Most CSO’s lack board presence and have no authority other than to be a speed hump. This has to change. Orgs who grew up overnight (like Google) will get hit –  and hard – by APT.

I don’t want to hear about APT unless you have a solution to whatever you’re bleating about. If you’re going on about how the script kiddies have all grown up and now do exactly what they did before, but are now bank rolled by intelligence agencies, my question to you is “so what?” If you’re doing IT security and governance right, APT is just so much hot air.