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: