A common disease that afflicts management and government administration the world over is the impression that “Our problems are different.” They are different, to be sure, but the principles that will help to improve quality of product and of service are universal in nature.
—W. Edwards Deming, Out of the Crisis
Security policy is the bedrock for controls and processes. An effective security policy serves the users, business processes, and technology of the organization. The policy should be universally understood and relevant for the current risks. This chapter explains security policies and how they should be developed and used.
What Is Policy?
How many times have you heard someone tell you: We can’t do that, it’s against policy. For some, it seems like policy is the blunt instrument used to prevent people from doing anything useful. True story: one organization had a policy that required a thirty-minute training session to use the bathroom. The pottypolicy was in place because the bathroom was on a different floor from the work area and it required traversing a secured area. Policy required that everyone entering the secure area behave in a certain manner. There were also special keys needed to access that area, which required additional key handling training. Essentially, it took eight different steps and a sign-off from the security department to relieve oneself. The ironic thing is that you can both see how this is necessary (access to a secured, scoped area) and absurd. That can be the nature of policy.
So what should policy contain? Policy is what guides people’s behavior at a high level within the organization. With an IT security program, the security policy flows directly from the ISMS charter and its defined goals. There should be one security policy for the entire organization that covers the organization’s stand on IT risk. There can be other policies, as well as other security documents, that support this top policy. Usually the top security policy is a simple, universal, and aspirational statement noting that the organization has risks and that everyone will work together to reduce those risks to an acceptable level. Most security policies are all the same; only the names differ.
What does the security policy do for an organization ? It’s how management communicates to the people of the organization about what it wants them to do regarding security. The security policy is the highest law of the land with respect to IT security. Legally, it demonstrates the organization’s commitment to the security program, which can be useful in both audits and lawsuits.
An organization should try to avoid creating a security document for every possible risk and control in the world (though some may try to). The security policy provides the purpose and target for the security program, so that even if there isn’t a specific policy regarding a situation, at least the intention is present to guide people’s behavior.
What Isn’t Policy
People unfamiliar with this kind of documentation conflate policies with procedures and standards . These documents have different names with differing purposes and audiences. At the highest level is the organizational security policy. Below that, additional policies are used to describe the high-level goals for various functions. Under those, you have standards to describe the acceptable level to which the policy must be implemented. Appearing last are the procedures that detail how the work should be done. Figure 11-1 illustrates this relationship.
Figure 11-1. Policy , standards, procedures
Therefore, you could have a policy stating encryption should be used for confidential data transmissions and storage. Then an encryption standard describes the acceptable encryption methods , like AES1 and key length. Then you can have procedures on how to set up encryption on various devices.
Another type of documentation is records , which are the proof that you did things according to policy, standard, and procedure. They can include machine-generated logs as well as meeting minutes, decision summaries, memos, schedules, and ticketing system notes. These are created as people do the day-to-day work. Records are what the auditors are going to need to see in order to validate you are doing what you’re supposed to be doing.
Chapter 13 is entirely on documenting procedures and standards. In addition, in each of the chapters on controls, there is more information on the kinds of policies, standards , and procedures needed for type of control examined in the chapter. This chapter is going to focus primarily on overarching organizational security policy.
Writing Policy
How do you go about writing the security policy? Before I get into specifics, you should consider few things.
Policy and the Law
Policy and the law are intertwined. Policies are written partly to ensure the organization is conforming to the legal or regulatory requirements of the organization’s industry. Security policy is no different. In your case, you are looking to conform to IT security laws, regulations, and contractual agreements. This means the written policy itself has deep legal implications. Poorly written policy can mean there are gaps or errors in your compliance coverage. Published official organizational policy that your staff cannot understand or do not follow can have severe legal blowback.
An incomplete or unimplemented policy at best is a non-policy. At worst, a policy that staff disobey or ignore can be considered a deceptive business practice. There have already been many significant legal judgments against organizations who have promised customers certain IT security protections that failed to live up to them. Here is just one example from the FTC case files:
Review your privacy policy and double-check that what you promise—expressly or by implication—comports with your day-to-day practices. Like any other claim, what you say about how you handle information has to be truthful and backed up with solid proof. The FTC’s lawsuit alleges that Myspace’s policy made assurances the company didn’t honor. 2
On top of the legal problems, your auditors will verify with your users whether policy is being followed. Be cautious about what you require in your policy. Include only the statements with should/shalls/wills/musts/mays that you know that users will obey. Having a policy that requires users to do things that they won’t or can’t do can only lead to problems.
Keep It Simple
Since your users need to read and understand the policy, you should make your policy as brief and readable to non-technical people as possible. Policy should be simple, not simplistic. It does need to encompass all of your high-level security and compliance requirements. That said, it is still feasible to do most security policies within a single page of text. Remember, this is the top-level security policy. The lower-level policies, standards, and procedures can be longer and do not need to be distributed to the entire organization.
Policies Don’t Have to Be Perfect
There is the temptation to make every policy perfect, to cover every possible situation, and to address every complaint. Don’t spend weeks or months in committee trying to hammer out the Magna Carta. Remember that policy is simple and broad. Take a reasonable shot at it and include a policy amendment process . As you find things that don’t work in your policy, update and republish it. You don’t want to change your policy every couple of weeks; once or twice a year is reasonable. If you need to, you can also include policy exceptions for certain departments or processes, depending on your scope and compliance requirements. Perhaps the security policy only covers the employees and contractors that need to follow a certain set of guidelines. For example, there may be a universal but weak security policy for all users and a more stringent policy for the IT department (who have elevated privileges and thus stronger rules).
Key Policy: Security Policy
The organizational security policy is the most important policy that you create with respect to your IT security program. It is the foundation for all of your other policies and a primary requirement for nearly every audit on the planet. Note that this policy is called the Written Information Security Program (WISP ) if you are a Massachusetts-based company and you need to comply with 201 CMR 17.00.3
What should be in your policy? Start with your ISMS charter. Some organizations use the same document for both, but it’s best to keep the policy simple since all users are going to read it. However, you can derive a lot from your ISMS charter, including the scope, purpose, and overview. Remember, you don’t need a lot of detail because the policy is a broad set of goals that everyone will be working toward.
Components of the Policy
There are some important pieces that you should have in your policy. These can be called out with section headers or they can simply be separate paragraphs. You can do whatever is most understandable for your organization. The critical pieces are explained in the following sections.
Scope
Scope describes who should follow this policy. If you aren’t having the policy cover the entire organization, then you can specify the groups of users and divisions. Scope should define the data and the IT systems that are covered by this policy.
Policy Goal
The policy goal is your high-level generic statement that says something to this effect: Security is good while leaking and losing data is bad, therefore we will have an IT security program to try to prevent the bad things from happening. Look back to your ISMS charter for ideas. This section usually looks the same across the board for all policies: We’re going to protect the Confidentiality, Integrity, and Availability of our systems. We’re going to follow all applicable rules related to the data we have in our possession.
Governance
Tell your users who owns this policy and who is responsible for implementing policy. This is where you designate a coordinator, like the CSO, and give them power to run the security program. The coordinator should have a direct chain of authority for security from the highest level of the organization. You should also lay out the fact that you’ll have ongoing maintenance of the policy, such as an annual review and updates. The governance section can also state that additional documents will be coming to flesh out this policy.
Risk Management
You should have a statement that identifies risk to the organization’s objectives and establishes controls based on those risks. If you want, you can spell out the control objectives here, but use brief, plain English. You can also mention that you’ll hold vendors and third parties to a certain standard and assess the risk of using them. Lastly, you can mention that your organization is aware that bad things will happen (assume breach) but you have processes in place to deal with it.
Expectations for User Behavior
The final critical section is your message to the users on what you need them to do. First, you need them to read and abide by this policy and any other policies that may come their way. Users should report policy violations. If a user is unsure about policy, they should ask questions rather than making assumptions. You can keep this section high-level, as you’ll have more detailed user behavioral expectations in the acceptable usage policy.
Sample Security Policy
So how does this look? Here’s a sample.
Goal
The Executive Management of ORGANIZATION is committed to protect all company information assets, from all threats, and to provide all needed resources to implement an Information Security Management System. For this purpose, an Information Security Policy for all ORGANIZATION information assets has been authorized. This policy’s purpose to enable core ORGANIZATION functions by protecting the confidentiality, integrity, and availability of ORGANIZATION’s data from unauthorized access, unauthorized modification, and unplanned outages.
Authority
TheChief Technology Officer (CTO)is the senior executive in charge of the ORGANIZATION’s IT assets. The CTO assigns and entrust the implementation of this security policy to the Security Officer.
Scope and Limitations
This policy applies to
All IT systems owned, managed, leased, or provided by ORGANIZATION;
All employees, contractors, and users of ORGANIZATION IT resources;
All data considered confidential which includes but is not limited to proprietary information, sensitive personal information, and intellectual property owned by ORGANIZATION or its customers or business partners
Security Policy Objectives
ORGANIZATION will
Maintain, approve, publish, and require acceptance of security policies, standards, and procedures that express the ORGANIZATION strategy for protecting IT systems and data.
Maintain appropriate security governance functions to establish, oversee, and evaluate the implementation of ORGANIZATION security controls.
Identify, nominate ownership, publish, and require acceptance of acceptable usage rules for system assets and data.
Ensure that all users understand their responsibilities, are aware of relevant security risks, and are held responsible for their actions.
Protect ORGANIZATION physical facilities, equipment, and digital media from unauthorized physical access, damage, or loss.
Protect ORGANIZATION IT networks and the supporting infrastructure from unauthorized access, corruption, or interruption.
Maintain and communicate IT operational roles and processes for controlling risk with technical processes including encryption, change control, configuration management, vulnerability management, and prevention of malicious software.
Control logical access to data and IT based on business requirements and roles.
Review critical systems and logs for signs of unauthorized access and damage.
Maintain, train, and follow secure application development and maintenance processes to minimize unauthorized access, modification, or downtime to developed or supported applications.
Maintain and communicate incident management processes to ensure quick reporting, tracking, remediation, and analysis of security incidents.
Review and track risks with third parties and business partners to ensure ORGANIZATION security objectives are met.
Review and update security controls and processes to maintain compliance with legal, regulatory, and contractual requirements.
Maintain, communicate, and test business continuity processes to mitigate unplanned interruptions and outages of critical system processes and networks.
Policy Governance
This policy is subject to change and annual review by the ISMS committee appointed and approved by the by Chief Technology Officer. Changes to policy will be communicated to all users in a timely manner. All users are expected to behave in accordance with this policy. Violations or questions about the policy should be brought to the Security Officer.
Approved by Chief Technology Officer
Dinah Might
Key Policy: Acceptable Usage Policy
The second key policy related to security is the acceptable usage policy (AUP) or data handling policy. Where the main security policy sets the tone for the entire organization’s security program, the AUP governs the user’s specific behavior. This policy is pivotal in guiding all user interactions with the organization’s IT equipment and data . Because this policy involves user behavior and can have severe sanctions for non-compliance, it should be written with the cooperation of the human resources and legal departments. You want to ensure that all of your users formally agree to this policy before allowing access to IT systems. The following discusses the major pieces of an AUP.
Goal
You should state the goal in this section. It’s not anything new: you want users to behave responsibly in order to protect the organization’s data and IT systems. It’s fine to repeat the goal from the main security policy and/or ISMS charter. The users have probably already heard it, but repeat it anyway. Repetition strengthens memory.
Scope
It’s likely this section is also repeated from the main policy. You could have a different usage policy for system administrators because of their elevated privileges. In that case, the scope could be slightly different and only cover the IT team. You could just as easily have a single scope that covers everyone’s behavior. Use whatever makes sense for your organization. Remember that nothing is set in stone. You could start with a single policy and then later decide to split the policy for admins or developers as the need arises.
Privacy Disclaimers
This is an important section and may vary by local jurisdiction. The essence of this is to warn the users that when they use organizational resources, they will be monitored and recorded. If users store things on organizational systems, then it can be searched. This is a privacy disclaimer saying that users have less privacy than they do on their own personal equipment. Some jurisdictions, such as the European Union, allow users to label folders or files as “personal” and they are treated as more private than organizational stores. Be sure to check with your HR department and legal counsel when writing this section.
The privacy disclaimer is absolutely essential if you need to do any forensics or incident investigations involving users. It is also required if you are going to do content filtering to block pornography or objectionable web sites, as well as any kind of e-mail filtering. All the users’ web traffic activity needs to be scanned for that particular control to work. It’s also needed for audit logging of administrator actions on scoped systems, which is a major audit requirement for many compliance systems.
Lastly, the privacy disclaimer can even call out a warning that if the organization comes across evidence of criminal violations on organizational records, law enforcement will be called and records will be turned over to them. In the United States, if you find evidence of child pornography on a machine, you must report the violation. You also may need to turn over internal records if there is a legal investigation involving any of your users. It’s a good idea to spell this out to users in advance. If nothing else, it might deter them from doing something they shouldn’t.
Handling the Data
Do you recall how data gets everywhere in an organization and Kevin Kelly’s description of the Internet as a copy machine? It’s important that you define confidential data to your users in terms that they understand. Give examples of organizational intellectual property and clarify who owns it (not the user). If users could potentially encounter a customer’s confidential data, explain what it looks like. Be sure to point out that they are custodians of their customers’ data, which these customers have entrusted to them for safekeeping. Explain how important it is that they not copy and send confidential data around carelessly.
Handling the Machines
Now that you’ve talked about handling data, you should talk to them about handling the hardware. This includes how they web surf, how they e-mail, and software usage. This is also a good opportunity to remind them again that users should have no expectation of privacy: if you use our equipment, we will watch you. Users can use organizational equipment for occasional personal tasks but there should be appropriate usage. Now that you’ve said that, you need so spell out what is inappropriate.
Define Misuse
Many things may seem obvious to a security professional that still should be explained. This includes the things user’s shouldn’t do, like surf pornography or download malware. Obviously, you don’t want people to do these things but you also want to warn them that you may discipline them if they do. Right out of the gate, users should not be pirating copyrighted materials using organizational equipment. They shouldn’t be surfing pornography or sending sexually harassing messages. No threats or spam, which includes sending mass e-mails about their favorite political cause or charity.
Another minefield of acceptable usage is bring your own device (BYOD ). You need to explain the rules for which types of personal hardware are allowed to touch the organization’s systems or data, if any at all. If users can bring their own hardware to work, like smartphones, what are the expectations? Can you enforce security controls on their devices, such as mandatory locking PINs? Can you do a remote wipe on the device if it has organizational data on it? This can get so complicated that you may want to have a separate BYOD policy that you require users to agree to before allowing the connection.
Another aspect of BYOD is BYOS, or bring your own software. You do not want users installing their own software, possibly full of malware and vulnerabilities. You can have a policy that all software on organizational computers must be approved by IT or security.
Social Media
It’s a dangerous line between allowing free speech and restricting what people can say about the organization on social media. You don’t want to stir up anger by telling people what they can or cannot say on their personal social media accounts. At the same time, you don’t want an employee tweeting out racist comments using their company smartphone.4
You need to make it clear that only certain departments or individuals are empowered to speak on behalf of the company. You also need to assert control over what users post from their organization-supplied equipment, such as nothing obscene or racist. You can remind users not to share confidential information about the organization.
Security Responsibilities
Finally, you need to spell out the responsibilities for the security that every user has. The first one is easy: it’s the user’s responsibility to be familiar with the security policies and to abide by the procedures and standards. Drilling down into that, users should use and maintain the security controls that they are given; no turning off their antivirus software to speed up their machine’s performance. You never want users tinkering with security or IT systems outside their authority. Explain that only the security department has authority to hack or audit internal systems. Along with that, tell them no sharing of passwords or authentication tokens.
You want users to report security problems, policy violations, and incidents immediately. By the way, when users report problems, thank them. It’s not always the most obvious thing to do (remember the “someone else’s problem” problem), so you need to encourage that behavior. Reminding that it’s their duty in the acceptable usage policy is a good idea.
Sanctions
After all that explanation, you need to put some teeth in the policy. Tell the users that if they violate policy, there will be consequences. You don’t have to spell them out here, but you need to mention that something bad could happen. More on sanctions is covered in Chapter 15, which focuses on people controls.
Sample Acceptable Usage Policy
Use of IT Resources
Overview
Users of ORGANIZATION’s IT resources need to observe these rules in order to protect the confidentiality, integrity, and availability of ORGANIZATION’s systems and data.
Scope
This policy sets forth the rules regarding employee usage of ORGANIZATION’s electronic media and services (computers, e-mail, telephones, voice-mail, fax machines, external electronic bulletin boards, on-line services, and the Internet).
This policy applies to all ORGANIZATION users, which includes employees, contactors, consultants, and temporary employees at ORGANIZATION.
This policy applies to all equipment that is owned, leased, or rented by ORGANIZATION.
Policy: Protect confidential data
Users should take all necessary steps to prevent unauthorized access to this ORGANIZATION and Personal confidential data. Examples of ORGANIZATION confidential information include but are not limited to company private, corporate strategies, competitor sensitive, trade secrets, and intellectual property specifications. Examples of Personal confidential information includes Social Security numbers, financial account numbers, addresses, and full names.
All users must protect confidential information of ORGANIZATION and personal confidential stored by the ORGANIZATION by obeying the following rules:
Confidential data must never be sent in e-mail or messaging in an unencrypted form. If an e-mail is received containing confidential information, the sender and the Security Department must be informed.
Confidential data must never be stored on laptops, workstations, or computing devices in an unencrypted form.
Confidential data must never be stored on cloud computing services, such as Dropbox, iCloud, Google Drive, and similar services without formal approval from the IT or Security department.
Confidential data must never be stored on portable media in an unencrypted form. Portable media includes USB sticks, hard drives, data tapes, or floppy disks.
Approved acceptable encryption tools for storing confidential data is available from the ORGANIZATION IT department. Only the specific encryption tools from the IT department are approved for confidential data. Users should not install their own encryption tools.
Limit Personal Use
Occasional personal usage of ORGANIZATION’s IT systems for personal purposes is understandable and acceptable. However, users may not use ORGANIZATION IT systems in any way that would be considered obscene, indecent, hateful, malicious, racist, defamatory, fraudulent, libelous, treasonous, or promoting the use of violence to others.
Users should not use ORGANIZATION IT systems for non-job-related solicitations, such as other commercial ventures or personal/political/religious causes.
All users must conduct themselves in a professional manner when corresponding with customers or colleagues.
Users must not connect personal computing devices to the ORGANIZATION networks without permission of the Security Department. Personal devices can be connected to the guest Wi-Fi network.
No Expectation of Privacy
ORGANIZATION reserves the right, without warning or permission, to review any employee’s data files, e-mail messages and usage records to the extent necessary to ensure that IT systems are being used in compliance with the law and ORGANIZATION’s policies.
ORGANIZATION will not guarantee that any electronic communications will remain private or confidential. For security and maintenance reasons, authorized individuals can and will monitor systems and network traffic at any time without notification.
ORGANIZATION reserves the right to access and disclose any messages sent over its networks and to monitor electronic activity without regard to content.
Copyright Infringement
Approved software includes all software provided to employees by ORGANIZATION IT department. Only software supplied or authorized in writing by the IT department will be considered approved.
Individuals may not take ORGANIZATION software home for personal use. Software audits will be conducted on a regular basis. Discovery of any unauthorized software will constitute a violation of this policy.
The use of ORGANIZATION systems to distribute, store, or collect non-business copyrighted media files, such as music or movies, is prohibited.
Social Media
Only the ORGANIZATION marketing department and executive management is authorized to speak in public on behalf of the ORGANIZATION. Employees are expected to use their best judgment when making personal comments on social media about the ORGANIZATION and distinguish their opinions as their own and not the ORGANIZATION. ORGANIZATION’s trademarks, logos and any other intellectual property may not be used in connection with any social media activity. Social media usage by employees when using ORGANIZATION property and systems is also subject to the terms and restrictions set forth in this Policy. Employees assume all risk associated with social networking and blogging.
Authorized Security Controls
If you suspect an ORGANIZATION IT system of being compromised or subject to unauthorized access, please contact the Security department immediately.
Users are assigned specific system ownership responsibilities and usage privileges associated with their specific job roles. Wherever feasible, ORGANIZATION has implemented technical security controls to limit access to authorized users. However, ORGANIZATION realizes that preventative technology has limitations. Users shall not to exceed or attempt to exceed their access privileges beyond their assigned scope of access.
Removing or disabling antivirus or security software without explicit written permission from IT is a violation of this policy.
Users must not perform or give permission to perform any security testing of ORGANIZATION without written permission from the Security Officer or Executive Management.
Consequences of Violations
If you need clarification of any aspect of this policy, contact the Security department.
Failure to comply with this policy may lead to discipline up to and including termination and all available legal remedies.
Policy Changes
This policy will be reviewed on an annual basis and maychange regulationsor requirements. Users will be notified of the changes and be required to acknowledge their acceptance.
Policy Rollout
The security policy and the acceptable usage policy are absolutely the right things to roll out as part of the security awareness training. After you explain the threats and attacks against the organization, you can then present these policies as your organization’s response. The Internet is scary, so this is why we all need to do these things. This is an also great opportunity to answer questions and clarify points about the policies. If you have to, you can roll these out electronically via video presentation or canned e-mail or video. It’s not as effective, but it’s better than nothing.
The best time to roll out all of this is when an employee first comes on board. If you can, have the HR department deliver the policies as part of their new-employee orientation. They’re already reading and signing a bunch of documents, so why not add this one? You should roll out policies once a year afterward and every time there is a change in policy.
One thing you need to do is formally capture each user’s acceptance of the policies. They can sign it at the bottom of the policy (put in a signature block) or agree electronically on some kind of policy management system (there are a lot available). Not only do you need this proof if you have to deal with a policy violation, but it’s essential for audit. You should also do this as part of every policy rollout, so annually or upon policy change. Your goal should be 100% compliance with policy acceptance. It’s not easy, but it’s not impossible either. Like everything else in this program, it mostly takes hard work.