I think you'd be amazed at how many organizations – especially small to medium-size businesses – do not have a written security policy. And these are building blocks of your security architecture, of your security life cycle. A security policy is a documented set of objectives for your company. It's rules of acceptable behavior for your users, and administrators, and root users. It also lays out the requirements for system and management to ensure the security of your network and computer systems throughout your organization. It's a living organic document, so it's never finished, and it's constantly updated. It's under continual improvement as technology changes, as requirements of employees change, as your business goals change.
A security policy will translate, it will clarify, it will communicate your management's position on security as defined in high-level security principles, not just for yourselves and your organization but also your partners, your vendors, and your customers to name a few. It's a bridge between management objectives and specific security requirements. It informs users, staff, and managers. It'll help specify mechanisms for security, your controls – administrative, technical, and physical. It provides a baseline – a security baseline – to build off of going forward. A comprehensive security policy will protect people and data in transit and in storage. It'll lay down the ground rules for expected behavior and Acceptable Use Policy. It will authorize the staff to do monitoring, to do probing, and auditing, and investigations. It will define the consequences of violations; that's very important, it has to have some teeth. And the most common element of a security policy is the AUP – the Acceptable Use Policy. And it should be as explicit as it can be to avoid ambiguity or misunderstanding.
So who is going to use your policy? Well, you'll have an internal audience to your written security policy, and you'll have an external audience. Externally, you want to provide a degree of confidence and assurance for your partners, for your customers, for your vendors and suppliers, and any consultants and contractors you work with. They're are going to be subject to particular aspects of that security policy, but they'll also be having the assurance that you're going to do all you can to protect systems, and services, and assets, and even more importantly people's lives, including their own, okay, and that comes to the disaster recovery policy, for example.
Then there is the internal audiences – your managers, your executives, your stakeholders, your Board of Directors, the departments and business units, the leaders of those business units, supervisors, technical staff, and of course end-users. And ultimately, we're all end-user, and it gets right down to it. Now one single document won't typically meet the needs of the entire organization in a large organization, so you'll have a kind of a general governance, and then you'll have smaller documents that lay out the security policy for the different business units or organizational units.
A comprehensive security policy
I mentioned the governing policy, which is kind of your high-level organizational treatment. It basically lays out security concepts, the scope. The intended audience here will be managers, and technical custodians, and supervisors. It controls all the security-related interaction between your business units or organizational units, the supporting departments in your company. In terms of the detail of the governing policy, it basically answers the "what" aspect, okay – kind of the overarching "what" question. Underneath that, you have your technical policies, which are the what, who, when, and where questions. And the end-user policies, which are the same thing – what, who, when, and where – but it deals to individual end-users and end hosts, okay, with the appropriate level of detail for the end-users. Now as Cisco security officers and technicians here, we are really more focused on the technical policies. That's where we really come in – the security staff members – to carry out our responsibilities for systems. These are a lot more detailed in the governing policy and they're very specific to the issue, or the system, or the application, or the Adaptive Security Appliance, for example. They might get into very granular detail about access control mechanisms and physical security issues, things that we're very interested in here in the IINS course.
Now your governing policy is not going to be very valuable to your organization unless it comes from a top-down mechanism. All of the aspects of it have to really come from senior management, right – the CSO, the CISO, for example. It's a statement of the issue that your policy is addressing. All of the security-related interactions between the organizational units and your organization – a statement about your position on the policy will be in the governing document – how it applies to your environment. It also mentions roles and responsibilities – maybe not by name, but by different types of roles in the organization chart. Also, what level of compliance to the policy is necessary – are you under federal or state governments, are you under Sarbanes-Oxley, or GLBA, or HIPAA for example. And then what actions, activities, and processes are allowed generally speaking and which are not allowed. And then you need to have some kind of global consequences for noncompliance, and this is going to be placed at the same level as all of the company wide policies, for example things like anti-discrimination, sexual harassment – those types of things, and it supports all the technical and end-user policies as well.
Technical and end-user policies
Now your daily operational maintenance and responsibilities will fall under what we call technical and end-user policies. And so this maybe the area that, you know, early on in your career you're going to be responsible for. These are a lot more detailed in the governing policy. They can be specific to the end-user operating system, specific to let's say the firewall system, the IPS, the application layer gateways, the secure router, the hardening of your network devices and your servers, that could be issue-specific, okay, for example physical security would be issue-specific. They may be printed security handbooks or published via XML, easily accessible to all of the end-users.
The end-user policy is a single policy document, and really it should be comprehensive – everything an end-user should know about, what they had to comply with and implement, and what are the results of noncompliance. Now there can be some overlap between end-user policy and technical policies because our administrators, our security staff, they're also end-users as well, okay, but it is at the same level as the technical policy. Bottom line is your user should have only one place to go to, one location to read a single document, to learn all they have to know to make sure they have compliance with your company security policy. Now usually, because this is a pretty long document, we're going to break it up in the different modules or different sections. For example, you'll have general policies, and of course they're the most important aspect is the AUP – the Acceptable Use Policy – how can use equipment and computing services, okay. And there might be account access request policy, you know, how do you request more access – escalated access – to applications and systems. There needs to be kind of a formal process for that. The assessment policy of acquisition – how do you acquire new laptops, how do you acquire new components. Audit policy - the policy of auditing and risk assessment. The end-users should know that they're going to be subject to that and possibly unannounced. You should have information sensitivity policy, okay, knowing about how things are classified and which things are top-secret for example. There should be a strong password policy, a risk assessment policy, and a global web server policy. So all of those things can fall under the general policies. And they get more specific to e-mail, remote access, telephony, application policies, for example, you know, things like what programs can you use, what can you not do, peer-to-peer file sharing for example. How can you use instant messaging would be a good one there. And there is network policies – what about your intranet and your extranet, okay, what are your network access standards, do you have technical policies for routers, and switches, and Security Appliances, and separate policies for servers. Do you have a wireless communication policy, that would be important as well.
Standards, guidelines, procedures
Now it's important to understand the difference between standards and guidelines, or procedures and policies. Basically let's look at this way, look at the circle there – the standards, and guidelines, and procedures all come from policies, so your standards will come from your policies.
Then your standards will be responsible for generating the specific granular guidelines and procedures. So the goal of standards is to improve efficiency, to make the things more uniform. They are typically mandatory and they are to accomplish consistency and uniformity, okay, those are standards. And again, we know that our standards are coming from our policy, so our policy is mandatory, our standards are typically mandatory.
Then you have guidelines. Guidelines are similar to standards, but they are going to be more flexible, typically not mandatory, and they could be best practices for example. They could be based on case studies - how we define standards in different scenarios or situations. So as security practitioners, our guidelines could be NIST computer security resource center information, NSA security configuration guidelines, common criteria, the rainbow series, other things.
Now procedures are typically required because they're at the lowest level of the policy chain and they're basically how do we do things, how do we perform specific tasks. We got to be careful here because if you know anything about Cisco or Microsoft – which I'm sure you know something about either one of those – there are several ways to do everything, okay, especially Microsoft, right. We could have a graphical way to do it through a GUI, we could do it through a console session or PowerShell. So we don't want to be too granular. So the things that are required are the goals, okay. So whatever the outcome of the procedure is that's the requirement. Following every single particular perfect step at order is not the requirement. But you are going to provide detailed steps to perform specific tasks and it's the performing of the task and the outcome that is typically required. So this is going to help us implement our policies, standards, and guidelines. These are also known as practices, your best practices.
|Standards||Specify the use of specific technologies in a uniform way|
|Are usually mandatory|
|Accomplish consistency and uniformity|
|Guidelines||Are similar to standards, but more flexible and not usually mandatory|
|Can be used to define how standards should be developed or to guarantee adherence to general security policies|
|Guidelines include NIST Computer Security Resource Center, NSA Security Configuration Guides, Common Criteria, Rainbow Series, and others|
|Procedures||Are usually required|
|Are the lowest level of the policy chain|
|Provide detailed steps that are used to perform specific tasks|
|Provide the steps that are required to implement the policies, standards, and guidelines|
|Also known as practices|
Responsibilities for the security policy
Now in your organization, a security policy is based to be a family affair. Everybody has a role and a responsibility, but everything starts at the top and flows down. As we know the governing policy, which is kind of the top level policy, needs to initiate by senior management – the CEO for example – and as well as in concert with senior security in IT management – that would be the CSO (the Chief Security Officer), the CIO (the Chief Information Officer), and the CISO (the Chief Information Systems Officer). Now you may not have all of those particular job titles in your corporation, but, you know, they are the senior security staff. They're responsible for the security policy, not ultimately responsible but that goes all the way to the top. But as far as the overall implementation of the governing policy, and the underlying technical, and then user policy, it goes to senior security and IT management. Then the directives will go to the senior security IT staff. They will have input on the security policy, they'll be part of the team, part of the steering committee for example, they may actually draft part of their security policies. Some of the different components, some of the sections for example, may have to rely on this security IT staff for wireless implementation and the wireless guest VLAN; they have the expertise, okay.
Then the implementation of that policy will be the actual security IT staff. And usually as a CCNA security or somebody who has passed the IINS exam, this is where we're probably going to start out, okay. That IT staff, the security staff, will be implementing the security policy, but we have some input, perhaps it depends on the size of the organization. But then ultimately, we're all end-users, so we all have a personal responsibility for complying with Acceptable Use Policy, and that means all the way up to the senior management – the CEO. And there should be specific language that refers to either getting written up or potential loss of employment if you violate the policy.
Something you'd really be aware of is the fact that there is so much lack of awareness and ongoing education and training done by all types of organizations. Malicious crackers and hackers are going to be able to defeat your technical, and administrative, and visual controls if you aren't having ongoing awareness programs and education and training. For awareness, you need ongoing webinars, webcasts, lectures, videos, CBT (Computer-Based Training), bulletins, articles – maybe providing awards for good practices, and then reminders – login banners, things printed out on mouse pads, notepads, and coffee cups.
You need ongoing security training for your end-users, and again, like I said, everybody is an end-user. You need awareness training for people in sensitive positions, technical security training for the IT staff, okay, sending your folks to IINS to become CCNA security for example; advanced information training for security practitioners – a CCNP security; maybe SANS training, and then all of this is going to help you lead to proper planning, proper implementation, maintenance, and of course you want to integrate periodic evaluation along with that.