Governance Security Policy - USALearning · PDF fileGovernance Security Policy . ... cycling...

Governance Security Policy

Table of Contents

Policies ............................................................................................................................................ 2

Policy Best Practices -1 ................................................................................................................... 6

Policy Best Practices -2 ................................................................................................................. 10

Types of Policies ............................................................................................................................ 12

Standards ...................................................................................................................................... 13

Procedures .................................................................................................................................... 15

Baselines ....................................................................................................................................... 16

Guidelines ..................................................................................................................................... 18

The Governance Analogy .............................................................................................................. 20

Notices .......................................................................................................................................... 21

of 21

Policies

26

Policies

Framework for the security program

Create a common set of expectations

Communicate management’s goals and objectives

Should be drafted by security officers, but with input from organizational functions

Require enforcement, compliance, and maintenance mechanisms

**026 Your policy is going to be the framework. You've already established your governance program. The board of directors has said that this is how it's going to be. Senior management has bought off on it. Your policy is going to be that framework that you hang everything on. It's going to come up with your expectations across the enterprise. What is everyone's job? What are they going to be held to? What are they expected to do? It's going to tell you what management wants you to do. That's useful.

of 21

You as the security officer, again, should write it, but you should get input from all those different offices. Do you really have to take it to legal? Man, they change happys to glads. That's all they do in there, right? And they send it back with all that red ink on it. Track Changes was one of the worst inventions ever. It just encourages those people, right? Who else do you give your security policies to to have them look at it while it's in draft form? Student: Management. Ben Malisow: Management. Good. Absolutely. They're going to make changes just so they look smart and pretend like they know what they're doing. Who else do you give it to? Student: Highly paid consultants. Ben Malisow: Highly paid consultants, so that they have an occupation. Student: Yes. Ben Malisow: Yes. Good. Who else do you give it to? HR? Why? Student: Because people are important. Ben Malisow: And children are our future. Yes, good. No, you do that-- that's a CYA measure, obviously, so that if there's any punishments that are listed in there that they are in accordance with the laws that govern

of 21

personnel. Also so that they can give you input based on certain things like what the HR department can and cannot divulge, for things like user profiles or how they're going to add new hires or what process they're going to play in people who are cycling out of the organization. Any other people who should be in on the draft of the security policy? The user community. Let's get them involved at this point. That's not necessarily a bad thing. Their comments and suggestions can be ignored at your leisure, but it's nice to see what they think of it and whether or not this policy is going to be something that's going to be transparent, like we talked about, where they're actually going to comply with it, or whether that's going to be something they're going to try to circumvent at some point. Depending on the nature and scale of your organization, maybe Public Affairs. Maybe your audit section. Are they going to like what they're going to have to be doing, what they're going to be called upon to do? Do they have the capability and the personnel and the budget to handle these new requirements? Good. Basically this is a huge, long process. Has anyone ever published a security policy, brand new, for an organization before? I was very, very lucky to have been involved in drafting and publishing the internal InfoSec policy for DARPA when I

of 21

worked there as a highly paid consultant. And it went through 53 iterations. From the original PowerPoints of, "This is what we want to do," all the way up through the actual, "Here's what we're publishing," and the paper copies. Yes, we used paper copies. It was weird-- 53 iterations and took about six months to publish that policy. And it went through just about every office in the agency so that everybody could hack off on it and say, "Okay, we see what's coming. We're going to comply with it." And your policies should have the stick and the carrot in there. It should say, "This is what's going to happen if you're not in compliance. This is what's going to do it." In the federal space, what is the biggest stick in there? What if the auditors say that this is not a good system, that it doesn't comply with all the requirements? What happens to that agency? Their scorecard gets published in the Washington Post, and that should suffice. But what is the real stick? What is the real thing that could happen, according to the law? Student: Funding gets cut. Ben Malisow: They could lose their funding. That system could be defunded. And that scares agencies pretty well. That really does. That works. Good.

of 21

Policy Best Practices -1

27


Formally define policy, create, and maintenance procedures

Should endure for 2-3 years

Don’t be too specific

Use forceful, directive wording

Don’t include technical implementation details or technical jargon

Keep it brief

Provide references

Review before publishing

**027 Here's some best practices that the book recommends for making your policy. Formally define it. I'm not sure what "create" means there in that context, but formally define your policy and your maintenance procedures for that policy. Why do you have to maintain the policy? We talked about reviewing it. What does maintaining it mean? What do you do when you make a change to the policy? Student: Communicate the change. Ben Malisow: Good. You're going to republish that to everybody who got copies of the first one. And what

of 21

else are you going to do? What do you do every Monday morning? Student: Yeah, change control, I was going to say. Keep a version of every iteration. Ben Malisow: Yeah. But it's a policy; it's not hardware. Why are we doing change control? Because six months later, when you've forgotten why you made that change-- you're going to be like, "This is stupid. Why are we doing that? Let's put it back the other way." If you have the change control and you've documented the reason you went from State A to State B, they'll save you that trouble later on of trying to remember what it was that you made that decision for in the first place. Or somebody else who takes over after you. You can hand them off those versions and say, "Here's how we got to where we are today." Policy. About two or three years for a policy. More than that, and you're probably going to be overtaken by events. Earlier than that, and all you're going to be doing all day every day is policy changes. Why not specificity? Why not specificity? I thought the whole point of it was to hold people to a standard across an organization. Student: Because if your policy looks like that book, nobody's going to read it.

of 21

Ben Malisow: This is a lovely book. Don't disparage the book. Yes. Yes. This is way too complex. Absolutely. Good. Good. Also, realistically, do you want to mention platforms in your policy? No. You might not even want to mention technologies in your policy, because it could be outdated as soon as you put it on the streets, right? You want to have enough general concept of "Information will..." and then let the other things be handled in standards or procedures, and we'll get to those too. Forceful directive. "Users probably should have good passwords." Insufficient for your policy. "Passwords will..." Right? "Thou shalt..." Strong, forceful wording. Again-- this goes along with specificity-- try to keep it out of geek speak if you can. Keep it nice and short. Like Andy said, no one's going to read this one. Provide references. You've made this like school all of the sudden. Come on, footnotes? Really? Why? Why? This is a sad, tricky reason. The reason you put references in there is because obviously if you work for your organization, you can't be smart. What's an expert? Someone from 50 miles away, right? It's a political thing, and it's a sociological thing. For some reason, internal people are never given the credit for having the answers. If you say, "This should go in the policy because it's a really good idea; this is the way it

of 21

should be," it has less credence than if you say, "This should go in the policy because the ITGI says it should go in the policy." "This should go in the policy because Carnegie Mellon said it should go in the policy." That wouldn't work here as much. "This should go in the policy because Purdue says it should go in the policy." Right? Student: That wouldn't work either. Student: That really wouldn't work. Ben Malisow: That wouldn't work well? No? Okay. Yes. But you want to be able to point to where you got that from, your sources. Good. And again, you're going to review it before publishing.

of 21


28

Policy Best Practices -2Require management signing

Require employee acknowledgement

Adjust policies with new input from incidents and developments

Define exception rules

Develop sanctions for noncompliance

Manage the information life cycle (e.g., on-site assessment, document exchange and review, process/policy review)

**028 Management has to sign off on it. Again, if there's no buy-in from the top, it's not going to flourish. This comes down to our acceptable use policy, right? You want the employees to acknowledge what it is they're going to be held to. That way when you do hold them to it, they can't say that they didn't know. You're going to adjust it. When you do your annual reviews, you're going to look at what's going on in your environment and in the world. Exception rules. Why would you make exceptions to policies? If

of 21

you're going to have a policy, why in the world would you have exceptions? Didn't you write the thing so it would be uniform? Student: There's always special cases. Ben Malisow: Always special cases. There's always the problem children, aren't there? Yeah. So there has to be-- there's always a process for adopting that, right? Good. Again, know what your stick is going to be as well, and make sure that the policy is enduring through the entire process, from cradle to grave, as they say. Right? Good.

of 21

Types of Policies

29

Types of Policies

Organizational or program policy (enterprise-wide)

Functional, issue-specific policy (e.g., Internet usage)

System-specific policy (e.g., for the financial system)

**029 Different types of policies that can be used in organizations. A security policy, enterprise wide, covers everything. "This is what our culture is going to be." In some cases, you actually publish subsets of policies. What are your users allowed to do on the web? Right? How are mobile devices going to be accepted into our environment? Those are good, issue-specific policies. Or system-specific, depending on what your lines of business are going to be. You want to write them according to what the need is going to be.

of 21

Standards

30

Standards

Provide the agreements that provide interoperability within the organization through the use of common protocols

Provide a more technical perspective than policies

Include hardware and software mechanisms

Require consistency across the enterprise

Cost-effective

Driven by policy

May refer to guidelines

**030 Difference between a policy and a standard. Who can tell me the difference between a policy and a standard? Go ahead, use any of the stuff from the slide. Go for it, Gayle. Student: Policies are the rules, things that are enforced. Standards are more of the guidelines for best practices. Ben Malisow: I'm going to give you that, sure. Even though we're going to talk about guidelines in a second. Yes. Yes. The policy states what you're going to do. The standards are more how you're going to do it. Good. That's why you're allowed to

of 21

get technical on these ones, and you can get down into the guts of the stuff too. And I'm going to go one step further: hardware, software, and wetware as well. It should be able to go that far down in terms of processes. Should be consistent. Again, except for those problem children we just referred to, you're going to want a common baseline for most of your systems across the build, because that'll be an easier way of maintaining everything. Cost-effective. Again, protecting things, securing things-- you're not going to spend ten dollars on a five- dollar asset. Your standards are linked to your policies, and might go to guidelines. We'll get to guidelines in a second.

of 21

Procedures

31

Procedures

Step-by-step instructions to support compliance with policies and standards

When drafting, include input from each affected functional area

**031 Procedures-- that's your checklist. That's your checklist. How are you actually going to do it? You've gone from, "This is what we want you to do, this is how we want you to do it," this is what you're actually going to do. And again, go to each different area and get their input on this, because if you ask them to do something they're not capable of doing-- if they don't have the training, they don't have the budget, they don't have the skill set-- they're not going to be able to follow your procedures.

of 21

Baselines

32

Baselines

Describe how to implement security configuration to ensure consistency

Specific rules describing how to implement the best security controls in support of policy and standards

Require periodic review

**032 A baseline is exactly like it sounds. It's getting a read of what the common build is going to be. It's going to be, "Everyone is going to have this out of the box. This is when they get a brand-new system. This is how it's going to look." Why do we do that? Why is it uniform? Why should the accounting department have a similar box to someone in marketing? Why should they look the same? Why should the desktop configuration be the same? Why should their passwords be the same? Not the same, but why should their password complexity be the same?

of 21

Student: They have similar job roles-- a need for tools and that sort of thing. Ben Malisow: But why should everybody in the organization have the same box, right out of the gate? Why should that box be common build? Student: Because it's easier to detect anomalies then. Ben Malisow: Good. Good. And it's easier to maintain, and it starts everyone at the same level. Now, if they need something customized, if the accounting department needs QuickBooks on theirs, okay. That's something that's added to their domain. But the common build makes it simple, gives you that baseline for everybody, and it helps you enforce those standards by saying, "Here's where everyone's going to start from." Should the baseline change? Of course. Of course. So do your periodic reviews.

of 21

Guidelines

33

Guidelines

Discretionary or optional recommendations

Provide implementation recommendations or suggested steps with implementing a policy, standard, or configuration baseline

Often come from frameworks created by external organizations (e.g., COBIT, CMM, ISO27000, etc.)

Combining documents• Don’t

**033 Guidelines. This is-- and this is where we were going to get to that word-- optional. They are not standards. They are usually external. They are suggestions and ways to avoid pitfalls that other entities have already acknowledged or survived. And there's a bunch of different guidelines out there. They help you craft your procedures. They might inform your standards, but they don't necessarily have to be adhered to. They don't have the rule of regulation or policy. Should you combine documents? Your guidelines-- mesh them with your standards? Put them together

of 21

with your policies? No. Don't do it. Don't do it. I know it's tempting. It sounds like it's a good idea. "We'll put it all together, right?" No. Don't do it. Keep them separate. When it comes time to update one, you want to update that specific one. You want to make sure that they're addressed on an issue-by-issue basis, a system-by-system basis, or a policy basis. If you need to change more than one at a time, change more than one at a time, but don't try combining them, because you end up trying to republish a policy when all you really needed to do was republish a procedure, which should be at a much lesser difficulty level. If you're going to change policy, who has to sign it? Management. If you change a process, the department can sign it.

of 21

The Governance Analogy

34

The Governance Analogy

Policy: “employees will nail boards together using a company-issued hammer”

Standard: “company-issued hammers will be 11 inches long, and made of fiberglass”

Guideline: “to avoid splitting wood, a pilot hole should be drilled before hammering”

Procedure: “1) position nail perpendicular to board 2) strike nail with full swing of hammer 3) repeat until nail is flush with board 4) if thumb is caught between nail and hammer, see Thumb First-Aid Procedure”

**034 Here's a great analogy that I wrote. This is how you define the difference between policies, standards, guidelines, and procedures. Policy says, "You got to use a company-issued hammer." Standard says, "All company-issued hammers are going to be 11 inches, and fiberglass." Guideline says, "You know, you might want to have a pilot hole before you start hammering." And then the procedure is the step- by-step checklist, including how to care for your thumb.

of 21

Notices

NoticesCopyright 2013 Carnegie Mellon University

This material has been approved for public release and unlimited distribution except as restricted below. This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.

The U.S. Government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. Government purposes, the SEI recommends attendance to ensure proper understanding.

NO WARRANTY. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT® is a registered mark of Carnegie Mellon University..

of 21

Governance Security Policy - USALearning · PDF fileGovernance Security Policy . ... cycling...

Documents

Transcript of Governance Security Policy - USALearning · PDF fileGovernance Security Policy . ... cycling...