The savvy sysadmin’s guide to surviving an ISO 27001 audit

If your Unix/Linux servers are to be involved in an ISO 27001 audit, there are a lot of things you should be doing ahead of time to ensure that they won’t end up generating findings. While there are many things you can do to secure the systems you manage, the key to getting a Unix system to pass an ISO 27001 audit is knowing what the auditors are likely to ask and what they will need to see.

What is ISO 27001?

If you’re new to the ISO 27001 standard, it might help to know that the standard sets a level of quality for information system security. That said, it’s likely that many of the things you already do today to keep the servers you manage secure and usable will play into the overall system security posture that the auditors will be looking to confirm. If you’re deficient in some way, there’s a good chance that one deficiency will be that you aren’t documenting your activities as well as the auditors might believe necessary. The standard incorporates many areas of focus, but maintaining records to prove that you’ve followed all the proper procedures is one that is easily overlooked in the busy day-to-day life of systems administrators.

The overall standard focuses on identifying and addressing risk in your organization — risk as it relates to information and related assets. Certification can be quite valuable with respect to gaining and maintaining customer trust. In fact, an ever increasing number of organizations are looking for companies that they do business with to be certified. Certification can also help to keep your organization’s big guys out of trouble as it helps to demonstrate that they’re using due diligence in protecting the company’s information assets, even if you’re the one actually managing the safeguards.

The focus of ISO 27001 is on managing information system security in its many forms, not just system security, but also building security, printout security, staff security, etc. and staff awareness and education are very important to being successful.

While the standard is referred to as “ISO 27001”, it is actually defined in a series of 27xxx documents, all related to information system security. The key documents, however, are 27001 (which discusses information security management system requirements and techniques) and 27002 (which provides a code of practice). Think of them as what you need to do and guidance on how to go about doing it. Organizations that want to be ISO 27001 certified will first look at what’s required and then determine how they can best go about meeting those requirements. For keeping systems physically secure, for example, they might decide that all servers must be situated in data centers with very limited access. They’ll write that requirement into one of their “controls”. And if, when the auditors come, they see the data center door propped open or unlocked, you’ll likely get what’s called a “finding” — something that counts against your chances of getting certified.

So, here’s a little ISO 27001 vocabulary for you:

• control — a statement regarding how specific requirements are met (e.g., “Servers will force account password resets every six months or less”)
• policy — a higher level statement regarding how information security is maintained
• finding — something like a demerit that counts against being certified (get too many of these and you won’t)
• OFI (opportunity for improvement) — a suggestion from auditors on an area where improvement is needed or is suggested. These will not count against certification, but could lead to findings if after repeated audits, no change has been made in the area for which the OFI was provided
• ISMS — the overall system that you follow, comprised of policies and controls, etc. that determine how you manage information security
• asset owner — the person responsible for a particular asset, the individual or group that takes care of it
• risk owner — the person with the accountability and authority to manage risks related to assets

You might have an option to read the standard, but this will depend on your organization’s arrangements with the provider. Copies of 27001:2013 and 27002:2013 alone are likely to cost you something like $350 (together) and these are *not* lengthy documents. That’s a fairly hefty price tag if you were going after your own copy. And keep in mind that ISO 27001:2013 is only 80 pages long and you will just get PDFs.

Whether or not your organization has a copy you can look over, what’s really important is how they’ve applied the requirements of the standard to your organization’s policies and controls. If those documents say that all printouts must be labelled with data classifications such as “company proprietary”, “management only”, or “highly sensitive”, that’s what you’ll need to do. The requirement for information labeling is in the standard. The specific labeling scheme is up to your ISO 27001 certification team to devise if you don’t already work with a clearly defined labeling scheme.

There are currently two versions of the standard that are in use — 2005 and 2013. If you’re operating under the 2005 version of the standard, however, you won’t be for long. It will only have validity until September 25, 2015 (two years after the 2013 revision was published) and that’s not that far off.

There’s an important change of focus between the two versions. Where the 2005 version stresses the role of asset owner, the 2013 revision changes this to risk owner. This may represent a serious change of focus for an organization transitioning from one revision to the other, but likely not. However, the distinction is important to pay attention to. Asset owners are likely to be people responsible for systems, documents, source code, etc. Risk owners, on the other hand, tend to be a little higher up the food chain — those individuals ultimately held responsible if assets are compromised. When risk assessments are performed, asset owners need to weigh in whether directly or through a proxy.

What’s a risk assessment?

A risk assessment is a process in which risks are evaluated and a determination is then made as to what should be done to address the risks. For example, the servers that you manage will have a certain risk of being compromised. To do a realistic risk assessment, you need to consider the value of the asset in question, the likelihood of compromise, and what actions or technologies are in place to prevent or limit compromise. Risks assessments will generally involve a numeric calculation so that they can be compared with other risks, thus establishing each risk’s priority. Risks above a certain level (likely determined by whoever manages security risks for your organization) should be addressed in some way, though risk acceptance is an option (generally with high level management approval) and some risks can be offset by insurance or other means.

As a systems administrator, you might well be involved in risk assessments because you will understand more than most everyone else how the security controls on the servers you manage work and whether they are effective.

You can read more about ISO 27001 risk assessments at this URL: http://www.itworld.com/article/2723652/it-management/how-to-do-a-risk-assessment-for-iso-27001.html

What is an audit?

The overall flow of an ISO 27001 audit will go something like this:

• The auditor will review your organization’s policies and controls and determine whether they adhere to the standard. This portion of the audit will likely involve those in your organization responsible for creating corporate policies and maintaining certifications.
• The auditors will determine whether you adhere to your policies and controls. They may ask if you know where the policies are stored and which apply to you. They might ask specific questions to determine whether you’re managing your systems as your organization’s control say you should. This part will involve people at all levels in the organization, basically showing that they follow the established rules.
• The auditor will ask you to demonstrate your adherence to your policies and controls. For example, they might ask if you have records that show that you review log files for evidence of problems or acquire approval before adding accounts to the servers that you manage. This part will involve those individuals involved in managing those logs and creating those accounts.

Audits generally involve auditors coming into your facility, asking questions of many people, collecting information, evaluating the information provided to them, and determining whether your organization is meeting the intent of the standard and following your stated policies. You will likely have only a modest idea what topics will be covered and what questions will be asked prior to the audit itself. The best preparation is likely to be reviewing what controls apply to you and confirming that you are following the practices that have been outlined in those controls. Always be asking yourself what records you have that can demonstrate that you are following the required controls.

One year, auditors showed up at my office door on Valentines Day. So, I wrote a Valentines Day card for them. On the outside, it said “Will you be my Valentine?”. On the inside, it said: Is there a control for that? Can you show me records? It’s not so much that auditors don’t believe what you tell them; it’s that they’re not allowed to believe you. They have to adhere to standards, too.

The auditors who show up to conduct an audit and determine whether your organization (or some part of your organization) will be certified to the ISO 27001 standard and will likely report on the findings and OFIs before they leave the premises. They are likely to have an agenda that outlines what they want to focus on, but this will also depend on whether they’ve conducted audits at your facility previously and the findings that might have been generated when they did.

What’s my role as a Unix sysadmin?

Anything that you’re required to do to meet ISO 27001 requirements should be written in your organization’s controls. When you read through the controls, it should be clear which requirements apply to you. Controls should have a documented scope that might be expressed as “applies to data centers”, “applies to development systems”, “applies to privileged accounts” or even “applies to all staff”. The scopes will help you identify what is expected of you.

The areas of focus will involve the servers you manage, the data resources that reside on them, who can access those servers and how those determinations are made (e.g., who approves), how the servers and data are secured, how passwords are set and complexity enforced, how risks are managed and how they’re addressed, how security incidents are managed, etc.

Your controls will probably require that your accounts be reviewed periodically to ensure that they’re still needed and that the account holders still have a need-to-know (need to access) for information resources that those account give them access to. You will likely be expected to periodically test backups to ensure that they’re usable and maybe to explain how those backups are secured to ensure they’ll be available when you need them. Are they stored locally or off-site? Are they labeled in such a way that their contents and their sensitivity is clear? Do you review log files and address issues that are revealed in the process?

Let me say this once more. One of the issues and the cause of many “findings” is often that, even if you’re doing everything right, you can’t demonstrate that fact. Keep records! When you review logs, when you test backups to ensure that they’re usable, when review accounts to be sure that only authorized users have access to your servers, document what you do. You might be very glad that you did.

Other questions you might ask yourself long before an audit is imminent include:

• Are documents and data classified according to their value and sensitivity?  Are the sensitivity levels clear and consistently used? Are documents labelled?
• Do you know what kind of information is stored on the systems you manage? Do you know its sensitivity level? Even if the system provides no way for you to label files, documenting the kind of information that is stored on each server will be helpful and will demonstrate that risks related to the systems you manage are realistic.
• Are you aware of who is ultimately responsible for risks associated with the information on your systems and the systems on which it is stored? Is the owner documented in some way? Would everyone on your staff give the same answer if asked?
• Does someone formally authorize the setup of accounts on the servers you manage or do you manage servers that are used by everyone in a particular group? Is this authorization documented on some way? When an account is requested, are tickets opened in a ticketing system or do the requesters simply send you email? Are access rights periodically reviewed? How often? What records are kept? Are you notified when someone leaves the organization so that you know to block those accounts?
• Do you keep tight controls on who has privileged (especially root) access to your systems? Are the passwords for those accounts changed periodically? Do you enforce secure passwords using system settings?
• Can anyone gain access to the servers you manage or are they secured in limited access data center? Are doors left open? Can people “piggyback” (i.e., follow each other into the server room in a way that requires only the lead person to open/unlock the door)? Are staff aware if what they need to do to maintain physical security
• Do you maintain a clear distinction between development, test, and operational systems? Are there barriers between them? Auditors might ask about the separation of these system types.
• What kind of documents might be sitting on your desk and those of your coworkers? Are the documents labelled in accordance with whatever labeling scheme your organization has devised?
• Do you periodically review log files? Do you keep records of these reviews?

How to interact with auditors

Audits are always somewhat intimidating. At least I have always found them so. I don’t want to be responsible for my company not getting its certification, but auditors are generally very reasonable and the things that they ask rarely come out of the blue. While they may know nothing at all about Unix, they’ve likely talked with a lot of systems administrators in their years of auditing.

When speaking with an auditor, be calm, be polite, and don’t ramble on about anything. Answer the questions and don’t bring up topics of your own even if you believe that doing so would improve your credibility. Don’t be afraid to say that you would ask your boss if you didn’t know how to handle some situation that the auditors ask about and don’t be afraid to refer to notes. If asked if you know where the controls or particular records are located, it’s perfectly OK to open a spreadsheet containing URLs that point to all the resources you might need. There’s nothing about the standard that says you have to keep all this information in your head.

Once you’ve survived a few audits, you’ll likely get the hang of it and feel fairly comfortable with the process, but a little review ahead of time is always a good investment.