cat slave diary

Category: Security

  • Intelligent Session Manager Architecture

    As security researchers, I think we’ve let down users in the quest to close down questionable and unlikely events. The problem is that even though unlikely, these events – such as MITM attacks – work nearly 100% of the time. They make great demos to scare folks who don’t understand what they’re seeing. It’s a shame that they just don’t occur in the real world all that often. So let’s move beyond “Expire it after 10 minutes”, and to a session manager that actually helps the business and makes users love you, and really close out some of these attacks.

    The reasoning behind 10 minutes is a balance between the business (who’d prefer no time outs really and would love to have a magic “remember me” function that is somehow secure) and Tin Foil freaks like me who know how incredibly simple MITM, session fixation, and session hijacking can be. Many of the goals of our advice has been based on 1970’s standards and thinking, and 1990’s type of attacks that still work, primarily because we’ve been asking for the wrong solutions, like short time outs and don’t let users log on twice.

    As Dr Phil says, “How’s that working out for you?”

    So let’s think about ways to improve session managers to blunt the known attacks. We know that TLS has issues with MITM attacks, but we’re very lucky that this is a local attack (for now). Such attacks are also exceedingly unlikely outside of security conference wireless networks, and motivated attacks on behalf of organized crime (very rare but devastating – see TJ Maxx).

    However, some of the other assumptions we’ve made when recommending bad ideas usually don’t think about the user of the application. My wife does all of our shopping online. The system is awful. It times out within a short period of time, and it usually takes 4 to 5 attempts to finish an order. I’m sure there’s some poor risk manager going “WTF? PCI is stupid – we have to implement 10 minute time outs for a process that lasts 30-40 minutes?” Let’s move beyond quick fire “gimme” penetration test results, and think about HOW the USER is impacted when we make recommendations with our consultancy hats on.

    What goes wrong if it takes 40 minutes to assemble a shopping list? Do we have a financial loss? No. Do we have a reputation loss. Yes. Do we have a shareholder loss. No. Do we have a privacy impact? No. Do we have a regulatory impact? Only if you consider PCI DSS a regulation worthy of its name. What can we do to make it better?

    With the online shopping example, losses start when we can order stuff. Easy! Keep everything intact (and allow items to be placed in and removed from the cart), but make the user re-authenticate to purchase or see their profile if it’s been more than 10 minutes. But with 100% of session managers today, that very act is impossible without significant customizations and we all know there’s some B List pen tester willing to ping you on long timeouts if you do write that secondary all singing all dancing session manager. THINK BEFORE YOU RECOMMEND RECEIVED WISDOM!

    Realistically, we need to set some baseline parameters for every session manager.

    • Strong. Session tokens should be random enough to resist being brute forced in a reasonable time frame. I still see this although it’s been solved on most platforms since 1996 or so.
    • Controlled. Session managers should only accept their own session tokens.
    • Session hijacking resistant. Session managers should rotate their tokens from time to time automatically. Every five minutes is fine, as is every request as long as there’s a sliding window of acceptable tokens to allow the most used button (Back) to work. All frameworks should possess a regenerate token API – it’s ridiculously hard in all frameworks but PHP today.
    • Session hijacking resistant. Session managers should watch headers carefully and reject requests that don’t perfectly match up with previous requests. There is no reason for a user agent or a bunch of other headers (upto and including REMOTE_ADDR) to change within a session.
    • CSRF proof. Session managers should tie themselves to requests, and check that the session and forms match up. OWASP CSRF Guard can do it, and realistically, this should be standard in every session manager.
    • Cloudy Web Farm support. It’s very hard to do federated session state with most session managers, and yet the hackiest solutions I’ve seen for getting around this issue is due primarily to the isolated session manager mentality. There are good last writer wins replication mechanisms around, including “deliver at least once” – not everyone needs this functionality, but those who do really need it badly. This can be used as a pre-cursor to…
    • Notifications. Most SSO products use work arounds so that the primary session manager times out before the SSO token does. This means that their are active SSO sessions you could reconnect to if you know what you’re doing. Let’s make it easy for folks like Ping to get notified when regenerate, idle, absolute and logout events occurs.
    • Adaptive timeouts. Sessions that “expire” should be put into a slush pool, that comes alive again up to an absolute limit. But the instant that a user wants to perform a value transaction, the session manager should require re-authentication.
    • Integration with common SSO protocols. SAML and WS-Federation are the two most popular SSO mechanisms out there. Realistically, all session managers should be aware of how these work, and tie into them strongly so that if folks use SAML/WS-Federation, this can be tied to the session token in use. How many times have we seen these two operate in completely separate worlds and then been a target for replay, session expiry and other attacks.
    • Destroy means destroy. Make it easy for devs to do the right thing when the user clicks logout. Not only clear the session properly, but also all associated copies of that token – headers, cookies, DOM, etc, etc.

    Notice that I didn’t put one of the lazy pen tester’s favorites in the above list – “Logging on more than once”. I REALLY don’t care about that. I care about what VALUE TRANSACTIONS you can do within the assigned sessions. If there’s a problem with value transactions, preventing two sessions at once isn’t going to save your bacon. Transaction signing / SMS authentication / re-authentication will help, or if it’s about resource consumption, then transaction governors like in ESAPI will help. THINK BEFORE YOU PUT STUPID THINGS IN YOUR REPORTS.

    Many of these items are in ESAPI. That’s awesome, but it would be nice if all session managers dealt with sessions to support users and business uses, rather than obscure and unlikely attacks.

  • The Impossibles

    I thought recently about the ways in which folks who are looking for research projects in web app sec might make a useful contribution to the field. Part of that is the list of impossible tasks – those tasks that are so hard that it is unlikely to be solved in my lifetime. If you solve these, you’re a rocket scientist.

    • Universal XSS Prophylactic – it seems simple enough – blow XSS out of the water. In all code for all time. We know how to do it well enough, but how do you solve it for all that crappy code still running? Think of a design pattern, injection, or mechanism that will blow XSS out of the water with minimal changes to existing code. Don’t say h().
    • The No Injection Design Pattern. Almost all of our major commercially successful protocols are mixed data / program (i.e. not Harvard Architecture). Think about a design pattern, architecture, or API that allows ANY arbitrary protocol (SNMP through XML) to have no injections. This is not just about prepared statements, this is about taking an injectable grammar, and transforming it into a work of uninjectable beauty that is orthogonal and deep. There is previous work in this area (and you’ll be off to good start if you know who wrote it and include them in your research team).
    • Common Off the Shelf Anti-Corruption Business Processes. Realistically, we’re here to support solutions, not enable security “features”. There’s no value to be had from security per se; we are the guardians against dumb luck and bad risk. There should be a open source business process library that is resistant to fraud, corruption, coercion and bribery, as well as just going from Step 1 to Step 10. Think of how a simple process of acquiring pens from the office supplies cupboard should be built compared to say acquiring a data center populated with 3843 servers. Or was that 3842 servers?
    • Working with infected platforms. Financial institutions know that a certain percentage of their customers are infected with malware. At one institution I worked at, it was approximately 35% of a Certain Popular Operating System had at least one, and more often 10 or more different pieces of malware installed, ranging from hostile toolbars all the way through to Banking trojans. We knew absolutely that their computers would most likely steal their logins, and try to steal their funds. Think about ways you can perform “trusted” computing on a clearly untrustable platform. Booting a LiveCD is not going to cut it for my Mum. Think harder. This one will make you millions if not billions if you do it right.
    • Creating a math or notation for access control that “proves” protection. This one is a big one. Many a time, we do code reviews and penetration tests and find insecure end points – client, presentation, controller, model, or data and we can exploit them. We shouldn’t be able to find these at all – your compiler and IDE should alert developers to leakage of secured data / functions. Come up with a notation or mechanism that can be easily parsed by compilers that helps prove that every piece of secured data and secured function is protected end to end. You must satisfy “principle of least privilege”, “default deny”, “fail safely”, and “complete mediation” principles.

    Some of these items are dealt with by OWASP’s ESAPI, others by the judicious use of WAFs. But there is huge scope with billions of lines of legacy code hanging out there in any number of languages and frameworks. These are simply never going to be fixed, and yet we rely on them to keep the lights on, water flowing and sewerage flushing. Literally. These are the first five that I think are worthy of top class researchers. Go for it.

  • How to get around censorship

    The Great Firewall of Australia is still being worked upon by the evil legal minions of Senator Conroy. At the time of writing, it’s not illegal to tell you how to bypass censorware. I’m hoping that the legislation has no retrospective provisions in it (which would be really evil).

    Here’s how you get around censorship in case Australia decides to become a totalitarian state and block free and unfettered access to the Internet.

    Free and pretty easy

    • Tor. Install Tor into Firefox. Done.
    • Anonymizing Proxies. This is the easiest path, especially if you don’t use Firefox. Find one that is hosted outside of Australia. There’s heaps available.
    • P2P software helps transfer files around, but I only use this for downloading Ubuntu ISO’s. Seriously. Don’t breach copyright – it’s how I make a living. P2P is not particularly secure, and can be monitored and seeded by hostile entities.
    • Most messenger programs allow file transfers. Again, don’t breach copyright. Most Messenger protocols are unencrypted and thus can be monitored, and realistically, how do you know the other party is not a dog? See Chat Roulette for proof of this principle.
    • Most transparent ISP caches only work on port 80, and can’t work with SSL due to the way SSL works. Use SSL.
    • Most transparent ISP caches only work on port 80. Go to sites on ports other than port 80, such as port 81, 8080 or similar.

    Free, but might cost you your job

    • Using head office’s proxy in another country. If you work at a large multi-national, use their proxy. Remember, most workplaces have anti-pr0n acceptable use policies, and they’re more likely to police them than Australia. Otherwise, Done.

    Not free, but still fairly easy

    • SSL reverse proxies. There’s a fair few of these services around. Done.
    • VPN’s. Buy a Virtual Private Server (VPS) in another country, preferably the USA. Install OpenVPN, PPTP or IPsec on it. Done.
    • Set up a local web proxy server that has child-parent caches. Set up a remote parent cache in another country, or subscribe to a remote cache service. Done.

    There’s more ways to bypass this stupid proposal, but I’ll leave those off this list for now.

    I seriously hope that there will be mass protests and heavy campaigning if there is any legislation tabled.

    We need to show Senator Conroy that the government is truly misguided on this – voters unanimously don’t want to be censored. Parents don’t want it. ISPs and our entire IT industry doesn’t want it. The ALP support base hates it. Censoring Australia WILL lose the ALP power. It will allow all the tin pot failed nations on the planet to say, “We have the right to do this, Australia did it.”

    We must resist this most evil proposal in any way possible. See you at the protests.

  • Welcome to iPad fraud

    In the rush to release hundreds of publication specific apps as quickly as possible, every media dinosaur is desperately trying to claw money from the cashed up iPad owners with micropayments and pay walls. This is a recipe for disaster – and it’s going to be a gold mine for security consultancies, and nothing but tears for users.

    Why?

    All of these apps have to implement their own pay wall, subscription model, and store regulated financial data. Whereas before Apple did all the hard yards, now Flash web designers are going to be cutting code in Objective C for the first time to handle credit cards.

    Are they going to get it right every time? Absolutely not. Will some of them get it right? Yes, those that get code reviews or have a skilled financial services development team. How many media outlets meet these requirements?

    Mark my words, there’s going to be a lot of folks making money out of the poor decision to not create a secure micropayments service for iPhoneOS.

  • Securency and bribery

    Australia developed polymer (plastic) bank notes from the 1970’s onwards, and they’ve been our currency since the 1990’s.

    This bank note technology is essentially counterfeit proof – notes can have holograms, microprinting, a transparent window, “watermarks”, very colorful inks, metallic strips, and the notes are long lasting and machine washable. There’s a lot of positives.

    The company that is formed by the Reserve Bank of Australia to print and market this technology is called Securency. They’ve been embroiled in a bribery scandal.

    I just don’t understand how a company with a technological monopoly (it’s hard to figure out how to print on plastic) let itself be the conduit for bribes, particularly in the countries where the bribes are alleged to have occurred.

    If I was a negotiator, and my opponent asked for a commission, structured deals, or outright bribe, I’d just report them to the head office, let them report to the other side’s local police, and then wait for the other side to appoint a new negotiator after justice has seen to be done. Their new negotiator would be so careful it would not be funny – you mean to do business, but the stench of corruption will not be tolerated.

    We’re talking central banks here. Countries that have corrupt central banks are failed states – we cannot and should not be a part of these countries.

    Like all financial institutions, the RBA and Securency employees and agents would have had to have undergone background checks, and yet many of their representatives and head office staff still committed a very serious crime – one punishable by jail time in Australia. Just remember background checks are an indicator of past criminal convictions, not future actions. Don’t waste money on them – just have strict anti-corruption policies in place, and walk everyone is tainted. The rest of the staff will get the picture more than a background check ever will.

  • Sticking your neck out

    For as long as I can remember, the standard “security” talk is a negative and destructive talk, where the presenter presents their latest “research” as if it’s going to solve world hunger, totally end the Internet as we know it, cure herpes, or put the spooks out of business as anyone could spy on the whole Internet.

    The reality is that a few hours, weeks, or if it’s someone like Oracle circa 2005, years later, the problem is solved and we go back to giving our identities away for free on Facebook as if nothing had happened.

    Seriously, why do we put up with this?

    I believe it is because negative Chicken Little (“the sky is falling”) talks are much easier to do:

    • Hand waving talks can be put together on the plane whilst going to the conference, or even later if you don’t hit the bar as soon as you get to the hotel. Talks of this type include “Why the IT Security industry sucks”, “This language is garbage”, “What you know is all wrong”, and my favorite, “PCI sucks”. These talks have zero merit because you can’t fix them. They’re opinion pieces barely better than a script kiddy blog entry, and are typically badly researched opinions rather than game changers.
    • The buffer overflow, CSRF, Ajax, RIA, XSS, SQL injection, or latest attack with a twist talks are easy to do. You might need to start working on these talks at the airport lounge, but you’ll still pump out a talk. Patches for these talks are sometimes delivered before the talk has finished. The world has not ended.
    • The fuzzing talk is is a bit harder. You have to run the fuzzer and let it find at least one badness. Probably a good idea to do it the night before you fly. Better yet, run it against a bunch of products in case someone did a good job.
    • Developing new devastating attacks that can be blocked by CS101-level controls, like the magic pixie dust of input validation. What a complete WAFTAM.
    • The pinnacle of negative talks has awesome demos, but realistically still demonstrates a paucity of ideas (such as how to detect if you’re in a VM – I mean really, who cares?). I have respect for these researchers, and really wish they’d apply their talents to good quality positive research instead of wasting their most productive research years on pointless baubles.

    Why are positive talks harder? Because you have to work at them!

    • Firstly, it’s about research, and original research is hard to do properly.
    • Research takes time, and consistent application to an idea that may not even pan out. But if you don’t do it, you’ll never know.
    • You have to find an area that is not yet solved. There’s a reason it’s not solved yet. These issues have made talented brains hurt already.
    • You have to think of a new and novel solution to the issue, and the solution should be effective, simple and cheap. Most of the speakers on the party circuit simply don’t have this capacity, and haven’t had an original idea in years.
    • You have to develop your solution and test it out against lab and real world scenarios to make sure it doesn’t suck. It helps if your solution is repeatable, your solution and code is documented, and its useable by others without sacrificing chickens.
    • Many folks write papers and talks as if they succeeded at first go. That’s not science, that’s puffing up Brand Speaker. We learn from the paths not taken more than the eventual solution. Think about CSRF and session fixation for example – there’s heaps of folks who think CSRF is solved by a random nonce. But it’s not the entire story. Same deal with click jacking. Write up your failures as much you write up your successes.
    • You have to hand your research and methods around to trusted peers to see what they think and hope they don’t spill the beans or steal your thunder. Once you’ve published, you need to make sure others can repeat your experiments and results.
    • If you want to change the world, you have to give it away. You can’t patent it. You can’t tie it up in trade secrets. You can’t keep it to yourself. This is the hardest of all – think of the IT landscape today if AT&T had kept Unix to themselves. Exactly.

    Lastly, and probably the most important – positive research and subsequent talks means sticking your neck out. Your peers evaluate what you’ve said and how your solutions work. If you’re not sure of self, this can be a huge risk to one’s ego. If you’re wrong, it’s real bad and you’ll be a virgin for another year. If you’re right, you will get {girls, boys, furries} and invites to all the sexy parties*

    I will not claim that all of the hundreds of controls I documented in the OWASP Guide 2.0 are right. In fact, I know some of them are wrong. That’s how science works. At least I stuck my neck out and documented what I thought at the time. I’m happy to come back to the controls, do the research to find new controls that do work with minimal cost, and document those.

    For those of you lucky to know me personally, you’ll know that I have no shortage of self, in fact probably enough self for two people, but you need it if you’re going to have a shot at this brave new world of repeatable, scientific progress in the web application security field.

    I hope to see more conferences like OWASP’s AppSec Research conference, to be held in Sweden this year. Make sure you go to it. More importantly, stop wasting time on negative talks, and get moving on doing that research for next year’s conference.

    * This is actually false advertising, as you’ll struggle to be invited to most conferences even though your research and talk will mean more long term than 100 negative talks. On the other hand, I’ve been told that Furries are easy to rub the right way.

  • OWASP ASVS – also good for architecture reviews

    I’ve just finished a job where I used OWASP’s Application Security Verification Standard as a light weight security architecture template.

    The good news is that it helped us decide a bunch of controls (using ESAPI of course) that will hopefully improve the security of the application. I’ll find out in a few months if any of it helped.

    What worked: pretty much everything.

    What didn’t work: Some controls are not relevant to some classes of application. Do your homework before you go into the meeting so you can skip over ASVS controls that simply can’t work.

    We found that there are controls we discussed that aren’t in the ASVS. The ASVS is a 80%/20% (Pareto principle) standard as pretty much all apps come from such a low basis today, so any security improvement is a worthwhile improvement even if it’s not milspec. I wasn’t too fussed that we missed a few key items.

    For those of you floundering around trying to figure out how to do Security Architecture reviews, ASVS can be your friend!

  • GMail – ORBS blacklist FAIL

    Hilarious fun for all the family. Google’s GMail service has been blacklisted by an ORBS product.

    These ORBS places are run by dumb ass vigilantes. The Internet just doesn’t need wanna-be-cops who have no legal basis for their operations. Just in case you’re wondering, I’ve been blacklisted by similar morons in the past and simply couldn’t get off their stupid lists, despite NEVER being a spammer and only sending maybe 30 messages a day from my host. Greebo, my not so clever cat, has more spam spidey sense than these oxygen bandits will ever have.

    So here’s the transcript:

    “Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 Rejected 74.125.83.43 found in dnsbl.sorbs.net (state 13).”

    Let’s look that IP up, as it’s not mine:


    % nslookup 74.125.83.43
    ...
    Non-authoritative answer:
    43.83.125.74.in-addr.arpa name = mail-gw0-f43.google.com.

    FAIL.

    Good luck getting off that list, Google! Let’s see if your billions of dollars and many lawyers will make it happen where my pleas fell on dumb ears.

  • OWASP Top 10 2010 – Cheat Sheet

    Here is a two page cheat sheet for the OWASP Top 10 2010.

    OWASP Top 10 2010 Cheat Sheet (100 kb PDF)

    Double side to create a single piece of paper and hand it out to all your developers for free – it’s licensed under a Creative Commons Sharealike with attribution license. Once I’ve had a bit of feedback and I’ve tweaked it a bit, I’ll donate it to OWASP.

    This cheat sheet is an unapologetically developer centric list of things to do right.

    I’ve made it as simple as possible by only including things that I personally know will work with the least amount of (re-)work. Therefore, I have purposely left out all the different alternatives. You can (and probably will) have differing views as how to do it better.

    The cheat sheet assumes the reader knows how to program, use a search engine and thus find OWASP. I might have to change these assumptions.

    I’d love to hear feedback. Comments or e-mail will work fine.

  • 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.