Nearly every security practitioner is familiar with the ISO27001 standard for information security. A lot of companies base their internal security policies on it and third parties use certification to it as a gold standard.

But, what do the statements, recommendations and controls actually mean? Working for very large organisations, I learnt them to mean very different to what I suppose they were intended and now that I no longer am a practitioner and the 2005 standard has been replaced by the 2013 version, I thought it would be a good time to share some of my internal thoughts.

I’d also like to thank Brian Honan for his help in putting this together – if anyone understands security standards; it’s Brian.

 

The Cynics Guide to ISO27001:2005

The meaning behind the requirements

A.5 Security Policy

Objective: To state the bleeding obvious.

A.5.1.1 – Information security policy document

To set the readers expectations, the standard requires the security policy to be documented. That’s right you need an actual policy document.

The standard doesn’t define what the policy must be written on, so you could harness your inner Moses and etch it out on stone tablets. Or alternatively record it on a tapestry, which would be far more artistic and you’ve got more chance of someone reading it.

A.5.1.2 – Review of the information security policy 

No-one has ever made money by selling something only once. Just ask any network marketer caught up in a pyramid selling scheme. The only way you make any real money is through repeat sales to family members who don’t have the heart to tell you they don’t need any more water filters.

Similarly, for a security policy to remain relevant, you need to ensure your policy is reviewed frequently; generating enough money to fuel the ever-growing population of security professionals wanting to leech off your company profits.

A.6 Organisation of information security

A6.1. Internal organisation

Objective: Keep your glass house in order before you collect some stones

A.6.1.1 – Management commitment to information security

Managers have a lot on their plate. In between the meetings, listening to their staff’s personal problems, trying to generate more profit they must show an unwavering commitment to information security.

Like most great ambition, there is no way of measuring just how committed a manager is to information security. I’ve always been a bit of a Jack Bauer fan, and how a bit of quick torture seems to resolve all issues. So next time you’re recruiting a manager, try electrocuting them for a little while. If they give up their mothers’ maiden name too quickly, you know they just aren’t cut out for management.

A.6.1.2 – Information security co-ordination

Keeping a firm grasp on your information is a team sport. A bit like football, you could have a great bunch of individual players, but to be effective they need to work together. Like the harmony of cogs in a switch watch, the elegance of an Olympic synchronised swimming team or how the A-Team manage to build a tank out of an old lawn-mower.

If you don’t already have delegated people to undertake these roles, you can land the job on an unsuspecting graduate as an offer to help them raise their game. Or alternatively hire a whole team of security co-ordinators and sit back and watch your empire grow.

A.6.1.3 Allocation of information security responsibilities

Every organisation needs scapegoats. Things won’t always go to plan and security breaches are bound to occur. In order to prepare, always allocate security responsibility to a suitable scapegoat. It will keep your image squeaky clean and nothing boosts shareholder confidence following an incident more than seeing the head of Information Security unceremoniously ousted.

A.6.1.4 Authorisation process for information processing facilities

Gone are the days when big Dave could just make a phone call to the guy at reception and ask to let you in. This isn’t Jerry Maguire where a person’s word is as strong as oak. You need to hunt down the person responsible (as defined in A.6.1.3 and get a DNA sample to prove they authorise your activities.

A.6.1.5 Confidentiality Agreements

Apparently if someone signs a document declaring that they won’t disclose any of their dealings with you to anyone, then that actually stops them.

A.6.1.6 Contact with the Authorities

If you’ve got a big company that tracks a lot of Joe Publics habits and activities, then big brother will want you to share some of the juicy gossip with them. So it’s best to have friendly a go-to man in the agency.

A.6.1.7 Contact with special interest groups

Stay in touch with geeks, nerds and dorks. You never know when they may come in useful.

A.6.1.8 Independent review of information security

Nothing screams “I don’t trust my over-paid incompetent security team” more than getting an overpaid incompetent outsider to independently review your information security posture. Get it done often, it keeps your staff on their toes.

Does not have to be an external person

A.6.2 External Parties

Objective: To keep external parties on a tight leash.

A6.2.1 Identification of risks related to external parties

It’s far easier to go all Columbo and find risks in external parties security controls. Makes you appear competent and you don’t alienate any internal departments.

A6.2.2 Addressing security when dealing with customers

Never miss an opportunity to remind customers how seriously you take security. It will bring them to trust you and do untold amount of business with you.

A.6.2.3 Addressing security in third party agreements

When in doubt, go through contracts with a fine tooth comb and expensive lawyer. Include your own specific security clauses that will make the vendors job more difficult and most-likely increase the cost of the contract; but you would have demonstrated how seriously you take infosec.

A.7 Asset management

A.7.1 Responsibility for assets

Objective: Know who to blame when a wrong decision is made.

A.7.1.1 Inventory of assets

Count all of your data assets and put them down in a spreadsheet. Of course, if you’re using a virtual environment that scales up and down frequently you may have to employ an intern or two in order that the list be kept up to date.

A.7.1.2 Ownership of assets

Nothing makes middle management feel more important than being told they own an asset. Also makes them convenient scapegoats when that asset gets exploited.

A.7.1.3 Acceptable use of assets

Write down commandments as to what is and isn’t allowed to be done with company assets. The more stringent these rules are, the easier it is for HR to hang any undesirables.

A.7.2 Information classification

Objective: To assign random levels of importance to information.

A.7.2.1 Classification guidelines

Produce vague guidance on how information should be classified. It should be ‘vanity compatible’ allowing self-important managers to assign the highest classification rating to their personal documents, or drop down to the lowest classification if an auditor is around.

A.7.2.2 Information labelling and handling

Because no-one will ever implement A.7.2.1, simply default all information to ‘public’.

A.8 Human Resources

A.8.1 Prior to employment

Objective: To give potential employees the impression this is a prestigious role reserved only for the best of the best.

A.8.1.1 Roles and responsibilities

Specify glamorous duties for the applicant that has no relation to what the job will actually entail. Never make mention of the schizophrenic boss they will be reporting to.

A.8.1.2 Screening

Conduct random background checks on potential employees, including checks that have no relevance to the actual role so that you may legally discriminate against those deemed institutionally undesirable.

A.8.1.3 Terms and conditions of employment

No-one ever really reads the terms and conditions, so build in enough clauses so as to allow you to fire anyone at any time without any repercussions.

A.8.2 During Employment

Objective: To keep all employees and contractors on a short leash.

A.8.2.1 Management Responsibilities

When not updating their facebook status, managers shall berate employees who create a security risk by using twitter.

A.8.2.2 Information security awareness, education and training

Destroy employees will to live by mandating they have to sit through 2 hours of powerpoint explaining the importance of security once a quarter.

A.8.2.3 Disciplinary process

In order to avoid having to pay out excessive bonuses to low grade staff, have processes in place that penalise any activity that may be perceived as having a security impact. NB. this is easier to enforce if A.8.1.3 has been properly implemented.

A.8.3 Termination or change of employment

Objective: To make sure users leaving the organisation get hit on the ass by the door on the way out.

A.8.3.1 Termination responsibilities

Someone within the organisation shall be given terminator responsibilities.

A.8.3.2 Return of assets

Take back any corporate assets the leaving employee may have. Where appropriate, erasing memory of departing employee should be considered.

A.8.3.3 Removal of access rights

Also known as the breakup clause. Akin to when splitting up with a partner, make sure they don’t have the keys to your apartment, or you could return home one day to find all your clothes burnt in the bin and your Twilight box set DVD scratched. If authentication was provided via biometrics cutting off hands or gouging out eyeballs can be a cost-effective method.

A.9 Physical and environmental security

A.9.1 Secure areas

Objective: Make everyone feel like a suspect by enforcing airport security style entry points.

A.9.1.1 Physical security perimeter

Build a great wall around your premises to keep the Chinese out. Then laugh at the irony.

A.9.1.2 Physical entry controls

Having a keypad on the door that only allows those with the special ‘knowledge’ of the PIN number will boost morale of those gaining access. For particularly sensitive areas, like the supply room, have a two-key entry system where two parties have to turn simultaneously in order to unlock the door. Bonus: acts as a good team-bonding activity.

A.9.1.3 Securing offices, rooms and facilities

Apply locks, lasers, motion detectors and other such controls to secure rooms in the building. However, leave a master key with the cleaning company to ensure it is kept clean.

A.9.1.4 Protecting against external and environmental threats

Protect against flood, earthquakes, meteors and other natural disasters. Once done, sell your anti-natural disaster technology on the black market for millions.

A.9.1.5 Working in secure areas

People working in secure areas shall be given guidelines on how to work because entry into secure areas instantaneously renders the most brightest people incapable of rational thought.

A.9.1.6 Public access, delivery and loading areas

Never let the pizza delivery boy enter the building. He’s most likely a spy sent by a competitor.

A.9.2 Equipment security

Objective: To prevent employees and visitors stealing your kit.

A.9.2.1 Equipment siting and protection

Put your valuable assets behind locked doors or apply some controls to reduce the opportunity for thieves to get access. e.g. Attaching a chain to your pens will prevent people ‘borrowing’ them for a long time.

A.9.2.2 Supporting utilities

If your power goes, or you forget to pay your water bill, don’t allow the disconnection of these services to hinder your business. Have alternative supporting utilities in place, like an army of hamsters in the basement, on wheels to generate electricity.

A.9.2.3 Cabling security

Don’t let a criminal listen in on your conversations by simply attaching two crocodile clips to your phone wires. Trace each cable entering and exiting the building and protect them with a layer of concrete.

A.9.2.4 Equipment maintenance

If it squeaks oil it; unless of course it’s a hamster in your backup power facility, see A.9.2.3

A.9.2.5 Security of equipment off-premises

Work some magical ways to protect your company’s equipment even when it’s not on premises. Deploying a portable force field usually works best.

A.9.2.6 Secure disposal or re-use of equipment

Clear the cache, overwrite the hard drive 600 times, put a nail through the monitor, remove all identifiable markings. Ask yourself the question, if that was your computer, and your partner or parent wanted to use it, could she get to see something you would rather they not?

A.9.2.7 Removal of property

In order to deter staff from removing information offsite without prior consent, enforce the TSA style checkpoints to operate both ways.

A.10 Communications and operations management

A.10.1 Operational procedures and responsibilities

Objective: To make sure the DJ doesn’t play any Justin Beiber.

A.10.1.1 Documented operating procedures

Users should have written procedures for everything from how to enter the building, the optimal position for displaying their pass, how to send emails and even how to use the toilet facilities in the most efficient manner.

A.10.1.2 Change management

It’s important to be a control freak. No changes can be made to anything without a committee reviewing and approving the change. It is not important for the committee to have any real knowledge regarding the security change.

A.10.1.3 Segregation of duties

Managers who have more staff are far more important within an organisation. Create double the number of jobs needed by enforcing segregation of duties whereby two people have to do the job of one.

A.10.1.4 Separation of development, test and operational facilities

Don’t let developers ever get close to the production environment. Then complain that they develop software that is incompatible with the production environment and give them access anyway in order to troubleshoot.

A.10.2 Third party service delivery management

Objective: Expect third parties to provide better security than you can at a fraction of the cost

A.10.2.1 Service delivery

Include a laundry list of security features in the service agreement with the third party. Laugh to yourself when they agree to the terms.

A.10.2.2 Monitoring and review of third party services

With the properly agreed terms, you can now keep a close eye on a third party like a stalker but without the risk of being slapped with a restraining order. Kick the tyres often and hard, making sure they are meeting your high security standards.

A.10.2.3 Managing changes to third party services

If the third party wants to change their bottled water supplier, you need to be all over it like a rash. Form an emergency third party change committee and ponder over the impact in great detail.

A.10.3 System planning and acceptance

Objective: Plan and plan some more just to be sure.

A.10.3.1 Capacity management

Make sure you have a big enough pipe, enough computing power and enough storage space. If not, the system will grind to a slow pace akin to an asthmatic snail running uphill, whilst breathing through a straw.

A.10.4.2 System acceptance

Once the system has been tested by school-age interns, it can be signed off as being acceptable and unveiled to the world.

A.10.4 Protection against malicious and mobile code

Objective: Get the APT outta here!

A.10.4.1 Controls against malicious code

Recommend any anti-virus solution and tick this box.

A.10.4.2 Controls against mobile code

Refer to 10.4.1.

A.10.5 Backup

Objective: To have a crew ready to rumble when things take a tumble

A.10.5.1 Information back-up

Take copies of everything. Storage may not be cheap, but having two copies of all the information will come in handy when the boss loses his collection of lolzcats

A.10.6 Network security management

Objective: All networks lead to Rome

A.10.6.1 Network controls

Put in place controls to manage and secure the network, not to mention protect data travelling over the network. Having a network diagram or basic understanding of the network layout is irrelevant. When in doubt, add another firewall, you can never have too many firewalls on the network. Ideally the network should actually be made up of an end to end collection of firewalls.

A.10.6.2 Security of network services

Security features of the network should be identified and documented as ‘guidelines’ for internally run and managed networks. For outsourced network segments, these features must be ‘mandatory’. Refer to A.10.2.1 for further guidance.

A.10.7 Media handling

Objective: Be media trained as you never know whether you could be facing Jeremy Kyle or Paxton.

A.10.7.1 Management of removable media

If media containing information can be removed e.g. pen drives, CD’s, DVD’s, hard drives, photographs, brains etc. there should be some documented procedures in place stating how these should be managed. This is best solved by inclusion of the line, “removable media must be encrypted” within the security policy.

A.10.7.2 Disposal of media

Media that is no longer needed should be stabbed with a stake, shot with a silver bullet and thrown into the sun to help the economy which would otherwise grind to a halt due to people recycling old media.

A.10.7.3 Information handling procedures

Provide guidance on how information should be handled. The threat of unemployment usually provides decent direction to employees as to how information should be handled.

A.10.7.4 Security of system documentation

Protect the system documentation, but not too well otherwise users needing information won’t be able to gain access – somewhere in between lies a state of zen.

A.10.8 Exchange of information

Objective: Keep your secrets with external parties safe

A.10.8.1 Information exchange policies and procedures

Have a formal procedure specifying what kind of rose to wear and which park bench to wait at whilst waiting for the “red fox” to arrive. Upon meeting of these conditions, the brown envelope containing the purchase order may be exchanged for the products.

A.10.8.2 Exchange agreements

Offer 30 day money back guarantees on all information exchanges with external parties.

A.10.8.3 Physical media in transit

Protect physical media by wrapping in bubble wrap. Instruct courier to resist temptation to pop bubbles in transit. For sensitive electronic equipment, shield it from radiation by placing inside a lead safe.

A.10.8.4 Electronic messaging

Information sent in e-mails needs to be protected. Of course, sending emails across the internet to an external party has its own technical issues. The best way to protect e-mail information is to include a 1400 word disclaimer at the footer describing how the e-mail is for the intended recipient only.

A.10.8.5 Business information systems

Where systems need to be connected or shared with external parties, make sure ground rules are in place. Not too dissimilar to sharing a bathroom in a house. Agreements typically cover whether the seat should be left up or down, how frequently the bath tub needs to be cleaned and the optimal amount of air freshener to be used.

A.10.9 Electronic commerce services

Objective: Secure your electronic commerce and you win the hearts and minds of customers.

A.10.9.1 Electronic commerce

Roll up your sleeves, dig deep into the trenches and take on the miscreants looking to cause harm to your electronic commerce systems by protecting against fraud, unauthorised disclosure or modification. When in doubt of your ability to achieve this, caveat heavily with the terms “APT” or “State sponsored attackers”.

A.10.9.2 Online transactions

When little red riding hood began her transaction to take dinner to grandma, the wolf mis-routed red, gained unauthorised access to grandma, ate her up and even masqueraded as grandma. Luckily the hunter was at hand to protect red and grandma, cut open the wolf and saved the day. You need to be the hunter and protect all your online transactions.

A.10.9.3 Publicly available information

Information that is publicly available needs to be protected from miscreants who would like to change it. Like those delinquents who would photoshop a moustache onto your CEO’s picture and claim it makes her look better. Given the different avenues by which information can be modified, having a strong legal presence and disproportionately suing the life out of a couple of teenagers will set the tone that you’re not a company to be messed with.

A.10.10 Monitoring

Objective: Know what your employees are doing all the time.

A.10.10.1 Audit logging

Hold evidence of users activities for an agreed period of time so that when building a case for negligence, you can bring up the event in 1998 when they locked out their account and wasted the helpdesks time.

A.10.10.2 Monitoring system use

A cheap resource should be employed to check the results generated by a monitoring system. No real effort should be made to explain what it is they are looking for. Simply scrolling through pages of logs should suffice, eventually they will see the matrix code.

A.10.10.3 Protection of log information

If a system administrator went rogue, all they would have to do is conduct their nefarious activity and then go and wipe the logs. However, protecting the logs against modification will ensure you can slap a pair of handcuffs on the perpetrator before they have the opportunity to leave.

A.10.10.4 Administrator and operator logs

Keep a close eye on administrators and operators. With great power comes great temptations.

A.10.10.5 Fault logging

Log all faults so they can be analysed. Unless the fault is in the logging system, in which case you probably need another system to log the faults in the fault logging system.

A.10.10.6 Clock synchronisation

Just like a covert team that is about to execute their mission, synchronise your watches. No-one ever explains how this is done, but the mere mention of watch synchronisation elevates the testosterone in a room by a factor of 4.

A.11 Access control

Objective: Access is a privilege, not a right

A.11.1.1 Access control policy

Make a policy on how people should be given access and what they should be given access to. In order to make your life easier, claim the access policy needs to be set according to business requirements. Therefore allowing you to sit back while the business struggles to define a policy, resulting in the catch-all access control policy of, “email Bob for access”

A.11.2 User access management

Objective: Users access isn’t going to manage itself you know

A.11.2.1 User registration

A good time to harvest users details is at point of registration. Tell them its for ‘security purposes’. Tie in the process to ensure you revoke access when required, but keep a record of all their details, just in case.

A.11.2.2 Privilege management

If everyone got access to all the data, it wouldn’t be very special. Keep a tight control over who has access to which resources, making people just through multiple hoops so they remember who’s in charge. This is especially true for information that is not really important, but by making it appear important you justify the existence of the security team.

A.11.2.3 User password management

New passwords issued to starters should be communicated in a secure manner. Smoke signals usually work, but if the building has a no-smoking rule try morse code.

A.11.2.4 Review of user access rights

To kill some time, check all the users and what resources they have access to. It’s amazing how highly you’ll be regarded when you randomly question users over their excessive access rights.

A.11.3 User responsibilities

Objective: Passing the buck

A.11.3.1 Password use

Users should be responsible for using passwords that are hard if not impossible to guess. Be longer than the Nile and contain those characters that require the simultaneous pressing of 3 keys to render.

A.11.3.2 Unattended user equipment

Any equipment left unattended should be protected. If a user leaves their workstation unlocked, it should be acceptable for anyone to send an email from their machine to the whole department announcing their resignation.

A.11.3.3 Clear desk and clear screen policy

Users should have a clear desk and a clear screen. It may appear as if they are not doing any work, but at least they will be in compliance with security requirements.

A.11.4 Network access control

Objective: He who controls the pipes that connect the interwebz controls it all

A.11.4.1 Policy on use of network services

Decide which services and protocols are allowed. Noting any exceptions executives may have to access P2P.

A.11.4.2 User authentication for external connections

If you allow users to work remotely, give them secure access to connect in from the external big bad internet. Along with the ID and password, provide them with a token, a maths challenge, a biometric reading and perhaps the most difficult of all, a captcha.

A.11.4.3 Equipment identification in networks

If you have a device connected to the network called, “red army supply unit” you may want to look into it.

A.11.4.4 Remote diagnostics and configuration port protection

Diagnostic and configuration ports must be protected both physically and logically. If you don’t know which of the ports are for these purposes simply turn all of them off one by one only leaving on those that make your manager shout at you.

A.11.4.5 Segregation in networks

Placing lots of internal firewalls will segregate your networks. Refer to A.10.6.1for further guidance.

A.11.4.6 Network connection control

If you share a network outside the organization you need to control who has access to what. A firewall will help.

A.11.4.7 Network routing control

Route traffic to keep it flowing in the way you desire. Routers can help achieve this.

A.11.5 Operating system access controls

Objective: Don’t let users make changes to the operating system, give them all a Mac

A.11.5.1 Secure log-on procedures

Make users log-on to gain access to the operating system.

A.11.5.2 User identification and authentication

Give users an ID. Preferably a number, the Nazi’s also used to give people numbers. Its not a comparison, just an observation.

A.11.5.3 Password management systems

The password system should force users to choose ridiculously complex passwords that expire every week, lock out after 2 wrong attempts and always at a time when they absolutely need access to the network.

A.11.5.4 Use of system utilities

Don’t let users have access to any program that may allow them to bypass your security controls or mechanisms. Allowing them access would be like giving out AK47’s to poor tribes you have oppressed for years.

A.11.5.5 Session time-out

If a user is not doing any work and is sitting idly for a minute or two, sign them out of all sessions. For added impact, send a notification to their manager highlighting the idleness of the user.

A.11.5.6 Limitation of connection time

Connection time should be limited because much like 1974, connecting to the mainframe for a long time deprives other users from running their commands.

A.11.6 Application and information access control

Objective: Applications need protection too

A.11.6.1 Information access restriction

Within the application, restrict access as much as possible.

A.11.6.2 Sensitive system isolation

If a particular system has sensitive information e.g. payment data isolate it from the rest of the computing environment. If access to data is needed, it must be given in writing to the computer operator who will look up the information and return it within 5 working days.

A.11.7 Mobile computing and teleworking

Objective: To secure information for those pesky remote workers.

A.11.7.1 Mobile computing and communications

Put in place a policy and deploy some technologies to protect information used by remote workers. If such technology is not available, install technology that will slow down remote workers to the extent they give up and decide to travel into the office.

A.11.7.2 Teleworking

Executives and IT can work remotely at any time. For everyone else, a teleworking policy shall be implemented to ensure remote workers are forced to work 3 times harder than their office counterparts.

A.12 Information systems acquisition, development and maintenance

A.12.1 Security requirements of information systems

Objective: To build in security from the beginning

A.12.1.1 Security requirements analysis and specification

Whenever a new system is being developed, a laundry list of security requirements shall be provided and subsequently ignored.

A.12.3 Correct processing in applications

Objective: Keep applications honest

A.12.2.1 Input data validation

Live the dream of trying to validate inputs. At the very least, for web-facing applications stick a WAF in front, it will tick some compliance box somewhere.

A.12.2.2 Control of internal processing

Validate early and often to assure data processing in proper manner, else data will become more corrupt than a 3rd world country dictator.

A.12.2.3 Message integrity

Don’t let your applications play Chinese whispers. Ensure the message stays the same throughout its cycle.

A.12.2.4 Output data validation

Data that an application outputs needs to be validated to ensure it is correct, else it can end up flapping its gums like a fired employee who still has access to a corporate twitter account.

A.12.3 Cryptographic controls

Objective: Protect the confidentiality, integrity and authenticity of information by mathematical witchcraft.

A.12.3.1 Policy on the use of cryptographic controls

Hire an academic to write a cryptographic controls policy, then hire someone to translate the policy into English. If budget permits, hire an artist to draw pretty diagrams to illustrate the points.

A.12.3.2 Key management

One key to rule them all, or no key gets left behind? Decide how keys should be used, generated, retired, bought back from the dead. Manage your keys well and you will unlock the true power of cryptography.

A.12.4 Security of system files

Objective: Don’t forget system files, they can be important too

A.12.4.1 Control of operational software

Don’t let anyone install software on operational systems. Create a committee to manage the installation as described in A.10.1.2.

A.12.4.2 Protection of system test data

Protect test data, or risk your competition discover you use Disney characters as dummy data and become the laughing stock in your sector. After all any good techie knows that only Star Wars or Star Trek characters are acceptable for use as test data

A.12.4.3 Access control to program source code

Restrict access to the source code, particularly anyone named Neo.

A.12.5 Security in development and support processes

Objective: Keep application system software and information wrapped up like a mummy.

A.12.5.1 Change control procedures

Refer to the mighty change management committee in A.10.1.2.

A.12.5.2 Technical review of applications after operating system changes

When operating systems are changed, review everything to make sure it is still working. Examples of such a major change was when the date changed from 1999 to 2000. Good planning and review procedures prevented a global computer meltdown.

A.12.5.3 Restrictions on changes to software packages

Don’t let anyone mess up your carefully packaged software which has been created with all the love and attention of a 7 tier wedding cake.

A.12.5.4 Information leakage

Information is born to leak, whether it be through mothers gossiping at the school gates or men trying to out-do each other. As the saying goes, beware of a small leak, for it can sink a big ship.

A.12.5.5 Outsourced software development

When you ask a bunch of developers working out of a shack in Bangalore to develop your software, keep a close eye on them. Or don’t be surprised when it doesn’t come back quite how you expected.

A.12.6 Technical vulnerability management

Objective: You may not know you have vulnerabilities, but you must hunt them, find them and fix them.

A.12.6.1 Control of technical vulnerabilities

Run a lot of vulnerability scans, both internally and externally. Take a look at the results and pass along to the IT operations guy with the memo, ‘prioritise, fix and report back in a week.’

A.13 Information security incident management

A.13.1 Reporting information security events and weaknesses

Objective: Make it easy for snitches to spill the beans on the weaknesses of others.

A.13.1.1 Reporting information security events

Encourage staff to report incidents quickly and through the right channels. Let them know that posting a screenshot on twitter isn’t usually the right channel.

A.13.1.2 Reporting security weaknesses

Don’t just ignore something. If you see a weakness or even suspect a weakness, please report it as soon as possible. We will reward you handsomely if your discovery leads to the firing of a colleague.

A.13.2 Management of information security incidents and improvements

Objective: Don’t be a cowboy or a hero or even a cowboy hero. Respond to incidents in a calm, collected and consistent manner.

A.13.2.1 Responsibilities and procedures

Define management responsibilities up front. It saves a lot of finger-pointing and name-calling in the heat of an incident.

A.13.2.2 Learning from information security incidents

Evaluate the cost of an incident, the potential future income loss and place the blame squarely on the shoulders of a third party. If there’s anything to learn from an incident, it’s always the fault of a third party.

Additionally, it’s important to remember that the third party is always a “sophisticated attacker” and that your security ninja skills were able to stop this “sophisticated attacker” before they gained access to your crown jewels. After all that sounds a lot better than a 10 year old kid was able to bypass all your security because you were too busy writing and developing policies rather than configuring your security systems.

A.13.2.3 Collection of evidence

Create all the evidence that is needed to defend yourself in court and save the company being sued out of existence. More importantly, a well-presented case will make you shine as a star despite the incident and you could end up with a promotion.

Also make sure that evidence contains all the emails you sent requesting budget approval for your security initiatives and the reply emails rejecting those requests.  This allows you to look even more of a hero and shifts the blame neatly away from you.

A.14 Business continuity management

A.14.1 Information security aspects of business continuity management

Objective: The show must go on

A.14.1.1 Including information security in the business continuity management process

When everyone is losing their cool in the heat of an incident, make sure they don’t forget to remain secure. Yes, it’s tragic that Bob may be trapped in the burning office, but you can’t let anyone gain access without prior authorisation even if they are wearing a firemans uniform.

A.14.1.2 Business continuity and risk assessment

Roll a dice or ask the magic 8-ball what the likelihood of an event happening is. Then based on this scientific evaluation build a risk assessment identifying what security controls are needed.

A.14.1.3 Developing and implementing continuity plans including information security

Plans need to be developed. These can be quite fun as you get to sit around a table and work out scenarios that may occur and what you would do to protect the security of information. Try getting batpoles installed to a secret underground cave into the plan for security reasons.

A.14.1.4 Business continuity planning framework

Make sure everyone know where the plans are, how to get to them and which version is being used otherwise you can find yourself trying to migrate users to an alternate site that was demolished 3 years prior.

A.14.1.5 Testing, maintaining and re-assessing business continuity plans

For some real fun, test out the plans. Better still, do a full dress rehearsal. You’ll look like you’re doing a great job, get a chance to wear your high visibility jacket and get to sneak off home after half day.

A.15 Compliance

A.15.1 Compliance with legal requirements

Objective: Tick those compliance boxes baby!

A.15.1.1 Identification of applicable legislation

Depending on where you are, where your customers are, the nature of your business, the type of data you collect, process, store and the locations in which the said data is collected, processed and stored will result in your company being subjected to no fewer than 27 different legislative requirements which all must be met despite several of them being contradictory to each other. Hire an expensive lawyer.

A.15.1.2 Intellectual property rights

Don’t download illegally and make sure you have enough licenses to cover all your users. If not, it’s easy money out of the bank.

A.15.1.3 Protection of organisational records

Keep records for as long as required. But not too long or that could fall foul of another legislation. Hire a records management person, which is kind of like a librarian, only louder.

A.15.1.4 Data protection and privacy of personal information

Don’t misuse customer personal information. Keep it safe. They tend to get very touchy if you don’t protect it very well, despite the fact they give out more information than that on facebook every day.

A.15.1.5 Prevention of misuse of information prevention facilities

Don’t let users use systems for their own personal use or other non-corporate uses. That includes using the mainframe to record fantasy football league scores.

A.15.1.6 Regulation of cryptographic controls

Some countries classify certain types of cryptographic technology as weapons. If you export these to undesirable countries, you will be dealt with the same justice as would meet an international arms dealer selling nuclear capabilities to Iran.

A.15.2 Compliance with security policies and standards and technical compliance.

Objective: To make sure systems and processes are compliant with your own policies.

A.15.2.1 Compliance with security policies and standards

Kick employees hard and frequently to ensure they comply with security policies and standards. There is no negotiation or grey areas. They are either compliant or not.

A.15.2.2 Technical compliance checking

Run technical scans and checks to validate systems are technically in compliance. Do not worry about the network overhead affecting user productivity, compliance is far more important.

A.15.3 Information systems audit considerations

Objective: To make auditors effective (snort)

A.15.3.1 Information systems audit controls

Get auditors to plan in advance, providing a detailed scope of audit and what systems they will be touching all in the name of ensuring the audit doesn’t disrupt any live business processes. In reality it gives you a chance to sweep everything under the rug, a bit like how you clean your house just before guests arrive. Except auditors are a bit like the in-laws, rather unwelcome guests.

A.15.3.2 Protection of information system audit tools

Protect system audit tools so that no-one can use them without authorisation. This includes auditors, because you don’t want them running covert audit operations without your knowledge.