nach oben

2016 | Buch

Kapitel lesen Erstes Kapitel lesen

IT Security Risk Control Management

An Audit Preparation Plan

verfasst von: Raymond Pompon

Verlag: Apress

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

This book explains how to construct an information security program, from inception to audit, with enduring, practical, hands-on advice and actionable behavior for IT professionals. Information security is more than configuring firewalls, removing viruses, hacking machines, or setting passwords. Creating and promoting a successful security program requires skills in organizational consulting, diplomacy, change management, risk analysis, and out-of-the-box thinking.

IT Security Risk Control Management provides step-by-step guidance on how to craft a security program that will fit neatly into an organization and change dynamically to suit both the needs of the organization and survive constant changing threats. Readers will understand the paradoxes of information security and discover handy tools that hook security controls into business processes.

With this book, you will be able to equip your security program to prepare for and pass such common audits as PCI, SSAE-16 and ISO 27001. In addition, you will learn the depth and breadth of the expertise necessary to become an adaptive and effective security professional. This book:

Starts at the beginning of how to approach, scope, and customize a security program to fit an organization.

Walks you through how to implement the most challenging processes, pointing out common pitfalls and distractions.

Teaches you how to frame security and risk issues to be clear and actionable to decision makers, technical personnel, and users.

What you’ll learn

How to organically grow a useful, functional security program appropriate to an organization's culture and requirements

How to inform, advise, and influence executives, IT staff, and users on information security

How to think like a seasoned security professional, understanding how cyber-criminals subvert systems with subtle and insidious tricks.

How to analyze, select, implement, and monitor security controls such as change control, vulnerability management, incident response, and access controls.

How to prepare an organization to pass external formal audits such as PCI, SSAE-16 or ISO 27001

How to write clear, easy to follow, comprehensive security policies and procedures

Who This Book Is For

IT professionals moving into the security field; new security managers, directors, project heads, and would-be CISOs; and security specialists from other disciplines moving into information security (e.g., former military security professionals, law enforcement professionals, and physical security professionals).

Inhaltsverzeichnis

Frontmatter

Getting a Handle on Things

Frontmatter

Chapter 1. Why Audit?

Abstract

A smooth sea never made a skilled sailor.

Raymond Pompon

Chapter 2. Assume Breach

Abstract

When intelligence folks smell roses, they look for the funeral.

Raymond Pompon

Chapter 3. Risk Analysis: Assets and Impacts

Abstract

The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one. The commonest kind of trouble is that it is nearly reasonable, but not quite.

Raymond Pompon

Chapter 4. Risk Analysis: Natural Threats

Abstract

There are many ways to look at risk. One way is to divide risk into natural, accidental events and man-made intentional acts of aggression. Both types of risk are important, but there is some insight to be gained in looking at them differently. This chapter explores risk arising from natural and accidental threats.

Raymond Pompon

Chapter 5. Risk Analysis: Adversarial Risk

Abstract

Intentional attacks against IT systems from motivated malicious attackers are the heart of the challenge in IT security. Malicious attackers work around your controls, actively hide from detection, and zero in on highly valuable systems and data. This chapter explores how you can analyze and predict adversarial attacks.

Raymond Pompon

Wrangling the Organization

Frontmatter

Chapter 6. Scope

Abstract

Scope, simply, is what you care about protecting based on what your compliance and risk analysis uncovers. The assets, processes, and personnel in the scope are where you focus your controls to reduce risk. Since it isn’t always feasible to defend all your assets from all the threats, scope answers the question about what must be protected. The following are some examples of scoped assets.

Raymond Pompon

Chapter 7. Governance

Abstract

Amateurs talk about tactics, but professionals study logistics.

Raymond Pompon

Chapter 8. Talking to the Suits

Abstract

Many years ago, the CTO asked me to a give a five-minute presentation to the rest of executive leadership regarding the recent risk analysis my team had completed. It was a huge project for the security team, spanning months of work examining every possible IT risk to the company we could imagine. The final report was nearly 50 pages long, filled with quantitative details on multiple sources of threats and multifaceted impact calculations. This was my first appearance before the entire executive team in a single room. Since I had only five minutes, I condensed our results into a handful of slides covering the top three risks. I arrived early and set up my laptop and the projector. As the execs strode into the boardroom, the CEO noticed my title page, “The Top Risks to the Company.” He asked as he sat down, “Oh, you’re going to talk about our competition?”.

Raymond Pompon

Chapter 9. Talking to the Techs

Abstract

There are times when the hardest thing a security professional can do is work with the IT department. It’s strange since many security professionals have come from an IT background. Speaking for myself, I moved into security from network engineering after a large firewall project. Of course, IT professionals work on security tasks their whole career, from cleaning up malware to managing user accounts and passwords. The IT team is on the front line of security every day. If your organization is hacked, they’re going to be just as busy as you are, if not busier. When the auditor delivers a failing report, it’s going to reflect on IT’s efforts. Even worse, high-powered hacking groups and spy agencies single out IT personnel as high-value targets. They know sysadmins have the best access privileges in the company. If they can take over their accounts, the whole network is their buffet table.

Raymond Pompon

Chapter 10. Talking to the Users

Abstract

Despite their great importance to the organization, users are best known to security people for just one thing: trouble. Users download malware along with their questionably funny cat videos. Users hate to patch their software. Users click links in e-mail. Users choose passwords based on the name of their dog. Users click through security warnings so they can get their job done. Users resist new security programs. Users break security, along with many other things.

Raymond Pompon

Managing Risk with Controls

Frontmatter

Chapter 11. Policy

Abstract

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.

Raymond Pompon

Chapter 12. Control Design

Abstract

Controls are what you use to reduce risk. Controls can reduce likelihood or impact, and if you’re lucky, they can reduce both. The selection and arrangement of controls is an important step in the IT security program. This chapter explains how to design controls.

Raymond Pompon

Chapter 13. Administrative Controls

Abstract

There is a tendency to lean for security practitioners to heavily on technical and physical controls. Machines do the same thing every time, forever and ever. Humans are more variable in their execution of tasks. However, we aren’t at the point where machines run themselves (I for one welcome our new robot overlords). Administrative controls are how you manage all this technology and associated controls in accordance with your stated security goals. We’ve talked about Courtney’s laws before. Now here’s one more.

Raymond Pompon

Chapter 14. Vulnerability Management

Abstract

Most of the time, you shouldn’t work too hard at being exceptional. You’re better off first making sure that you avoid doing anything too stupid. If you are hacked because of some unpatched hole that’s been sitting around for months, you will look stupid. Where did that hole come from? We know that no matter how secure we make our systems, new vulnerabilities will be found. Your challenge is to find and fix the holes before the attackers exploit them. The process you use is called vulnerability management. It is a process that combines both technical and administrative controls, calling upon many different aspects of security and coordinating work between different departments.

Raymond Pompon

Chapter 15. People Controls

Abstract

There’s a lot in this book so far about working with people. As the element with the greatest variability in your security program, people can make or break your efforts to manage risk. This chapter focuses on controls explicitly for dealing with people. In most sizable organizations, there is a human resources department (or person) dedicated to overseeing personnel operations. They have an instrumental role in building and managing the security program.

Raymond Pompon

Chapter 16. Logical Access Control

Abstract

When you mention access control, most people’s minds go blank. Those few that understand technology usually think of passwords. When I think of passwords, I think of an organization that I worked with that had arguably the most difficult password policy I had ever encountered in my working life. The policy read: Passwords are required to be 12 characters, containing one symbol, one number, one lowercase, and one uppercase letter. Passwords must be changed every 45 days and new passwords cannot be related to previously used passwords. Passwords should never be written down or shared.

Raymond Pompon

Chapter 17. Network Security

Abstract

Imagine a network worm using a variety of attacks to infect the most popular operating system on the Internet. The author of the worm was so technically skilled that within hours of being launched, it infected one out of ten machines on the Internet. It was called the Morris worm after its creator Robert Morris, a computer scientist. The worm hit in 1988, before some people in the security field were even born.

Raymond Pompon

Chapter 18. More Technical Controls

Abstract

This chapter covers several other major technical services that require security controls. Once again, you may notice that the emphasis for effective security is on good basic practices like simplicity in design, security standards, and maintenance. As always, I urge you to think about what you need to accomplish with respect to risk reduction before you start implementing technical solutions or start buying tools. Fix the problems you need to fix and make sure that your operations team can maintain them and you have sufficient time and expertise to review their output.

Raymond Pompon

Chapter 19. Physical Security Controls

Abstract

The interesting thing about physical security is that some security folks write it off as not my problem. We too can be victims of the Someone Else’s Problem effect. In 2016, the California Attorney General reported that 22% of all reported breaches came from physical theft and loss. Physical security problems were second only to malware. As much as we IT security geeks would like to distance ourselves from physical security problems, it’s something we need to address.

Raymond Pompon

Chapter 20. Response Controls

Abstract

How you react when things go wrong is a huge factor in how much damage an incident does to your organization. If you run around like your hair is on fire, things will not go so well. When we are busy or stressed, we make bad decisions. There is panic, confusion, and indecision. Who is in charge? What do we do? Who do we call? This kind of disorder can magnify impacts and turn a bad situation into a disaster. However, if you remember the assume breach principle, then you know incidents are inevitable and you can be ready. What do you need to do to be ready? It involves three principles: preparation, planning, and practice.

Raymond Pompon

Being Audited

Frontmatter

Chapter 21. Starting the Audit

Abstract

Once you have all of your controls in place and running smoothly, you can think about auditing them. A successful audit is the closest thing you‘ll get to proof that your organization is secure. Which audit should you consider? You probably won’t get to choose as most audits are thrust upon us. If you’re lucky, you’ll only have to deal with one audit instead of several overlapping ones. All of the processes and controls discussed in this book are applicable to SSAE 16, ISO 27001, PCI DSS, and other major audit requirements. So where do you begin?

Raymond Pompon

Chapter 22. Internal Audit

Abstract

A corollary to assume breach is to assume control failure. In the words of many a CIO, if you don’t check it then it wasn’t done. Anyone who has managed operations or service vendors knows that some IT workers have a different definition of dones than you. Given time and exposure to the real world, things drift from their modeled description. Policies don’t match what people are doing. Project status updates are inflated. Network diagrams aren’t current or complete. Log data isn’t captured or if it is, the data slumbers unanalyzed somewhere. People leave the organization but their accounts remain active. Implementation projects get paused mid-implementation because of operational emergencies, but they are never resumed. Maintenance slips and patching doesn’t complete. I’m not pessimistic—this just happens in a large, busy IT organization. However, if a control isn’t working as described by policy, then you need to find it and fix before the auditors or attackers spot them. That is what internal audit is about.

Raymond Pompon

Chapter 23. Third-Party Security

Abstract

Every organization is dependent on other organizations outside of itself. It’s unlikely that your organization writes all of its own software, builds its own hardware, owns the buildings it occupies, and is an internet service provider. Your security is dependent on many of these things but if they are produced outside of your organization, your control is limited. Previous chapters touched on risk and controls for third parties, but what happens when those third parties are critical to your scoped environment and audit? You need to manage the security where the third party touches your scoped environments. Before you manage, you need to measure. To measure the security of an outside organization, you need to use everything you’ve learned about being audited and apply it to someone else. Even if you pay someone else to audit the third party, you still need to define the scope, requirements, and testing, and interpret the results.

Raymond Pompon

Chapter 24. Post Audit Improvement

Abstract

So now you’re done. Your security program is up and running, you’ve made it through your audit, and everyone is happy. Take a vacation and rest. You can forget about security, forever. Yeah, you know I’m kidding. As long as there are threats in the world, the security team can never close their eyes.

Raymond Pompon

Backmatter

Titel: IT Security Risk Control Management
verfasst von: Raymond Pompon
Verlag: Apress
Electronic ISBN: 978-1-4842-2140-2
Print ISBN: 978-1-4842-2139-6
DOI: https://doi.org/10.1007/978-1-4842-2140-2