What Is A Security Program? How Do I Build A Successful Program?

Transcription

1 What Is A Security Program? How Do I Build A Successful Program? White Paper A Security Program is like building a house, the standards provide you with a list of parts needed to build the house and a proven methodology provides you with a process to construct the house. Mike Gentile EVP of Innovation & Security Author of The CISO Handbook La Alameda, Suite 100 Mission Viejo, CA

2 Objective As the security landscape has become more threatening and dangerous and many organizations have fallen victim to attacks, breaches, and unrelenting news coverage, most have been forced to finally react in an effort to protect themselves. One of the first actions they have done is to apply more significant budget and resources to addressing their overall security effort. As more money and energy is poured into security, so has the emphasis by organizational management to ensure that a systematic approach is used to employ these resources in the most effective manner possible. In security speak; this is called Security Program Development. Actually, it is called Security Program Development, Information Security Management System (ISMS), Security Plan in government, and about a 100 other different things depending on your perspective and the perspective of the person that taught you about it. This has created an interesting situation. As organizations now want Security Programs more than ever, many organizations have been confused by the myriad of techniques and approaches that exist, especially now when time is of the essence. This paper seeks to address this confusion by looking at some of the available Security Program Development methodologies out there. Once this foundation has been established, this paper will then look to build on this new level of understanding with some actionable techniques for moving your Security Program Development efforts forward. So before moving on to some of the existing approaches out there, we will first explore why building a repeatable Security Program for your organization is important. Why Do I Need a Security Program The development of a repeatable system for addressing information security within your organization is important because it is the only way to effectively enable informed business decisions by management about security, and then to support the execution of those decisions on a consistent basis moving forward. Without these two critical items, an organization will never know how much to spend on security, what to spend it on, as well as how well their security investments are working once committed. These uncertainties are usually not very good things in an organization that is looking to make an investment, or wanting to know how one is performing. Finally, one disclaimer and the first tip: A repeatable system for addressing information security is the only way to effectively enable informed business decisions by management. Disclaimer: For the last 3 years I have been doing work primarily in healthcare, but have built Security Programs in just about every industry. The ideas in this white paper are directly applicable to healthcare organizations, though you might not see much that seems directly specific. This is for one reason and one reason only. If you are approaching your Security Program Development efforts within a function driven process based approach, there is no difference in that approach if you are building a program for a critical infrastructure, financial institution, county government, or anything in between. In fact, if you are 1

3 implementing something that can only be implemented specific to say a hospital, then more than likely your approach will fail. Alright, so what is a Security Program so I can get one started Common Security Program Definitions As mentioned in the introduction, there is a long history for how the concept of Security Program Development has been used within the security community. For those of us that have been doing this security game for a while, I remember even five years ago when I would meet with senior management at Fortune 500 organizations and when I said they needed a Security Program, they would say can I get it at Office Depot? In healthcare organizations, which tend to lag a bit on security, this occurred not that long ago. While it is clear that organizations were not ready for Security Programs five and even two years ago, the security community, in our quest to be accepted, did develop a myriad of approaches, frameworks and documentation to implement and/or define a Security Program. We took it one step further and published a book on the subject. Ours was called The CISO Handbook, which was written in 2003 and published in 2005, but has sold more copies in the last year than all the previous years combined. In general, most of the approaches and books on this subject are still relevant today. What has changed is organizations were not ready to spend money and build a real program a few years ago. Now they are which for the first time really gives the security community a compelling business purpose to implement these programs. Let s explore some of these approaches to add some clarity to the subject. When it comes to Security Program Development, there are three primary frameworks of information that can be utilized. We will attempt to summarize them here, as well as provide some pros and cons for you to consider specific to using one of these frameworks for your healthcare organization. The approaches to security haven t changed much over the years; it s the desire and need for Security Program Development that has changed. 1. The NIST Approach The National Institute of Standards and Technology (NIST) have been documenting approaches for developing a Security Programs since early 2000 s. In the government world, developing a Security Program is generally called a Security Plan. Yes, this is a nebulous term for a nebulous term, which is why so many organizations and people get confused with all this stuff. Below are the documents within the NIST catalog that address building a security plan or program. There is no doubt that we may have missed some by the way, but here are the main ones that most of us know about. 2003: NIST Guide to Information Technology Security Services 2006: : Information Security Handbook: A Guide for Managers 2

4 2007: : Guide for Developing Security Plans for Federal Information Systems 2013: Security and Privacy Controls for Federal Information Systems and Organizations v4 In general, for a healthcare organization, understanding the recommendations and guidelines of NIST is critical for one reason. Though not mandatory, the majority of HIPAA security rule points to using documents and standards created in NIST. As a result, many lawyers, particularly in breach situations, are recommending using NIST for building a Security Program. Over the next couple of years, this is going to lead to chaos. The majority of NIST frameworks for building a Security Program do not present a systematic approach, but instead a list of categories and areas that you need to include in your program. In fact, of all of the frameworks, one of the only process-based approaches, which make it customizable and functional, can be found in the first ones published in NIST In many of the other frameworks, they will illustrate areas you must build for a Security Program, such as Incident management or appoint a security officer, but they will not provide how to do it or provide the functional requirements for what is the right incident management plan or security officer to hire. It is like you are building a house, and these standards provide you a list of parts your house must have such as walls, and windows and doors. What the standards don t do is provide you with what your house must do or what is the functional need, or more important how to determine those needs. For example, is your house going to be in the Artic, or in the Bahamas? The functional needs for both of those environments are going to be quite different, and if you don t have a way to consider those requirements, you are going to build the wrong house. NIST is not clear with providing such insight, and this insight is critical to building the right program. Making this a bigger risk is that the NIST frameworks are getting more and more robust. NIST v4, which is the latest to provide direction, is providing parts and requirements to build the largest and most complicated houses known to man. In my opinion, the majority of organizations that take on using this most recently released framework and standard to implement a Security Program and supporting controls, is going to be building something that will be unusable to most businesses. I like to call NIST v4 the Winchester house of security. If you choose to take it on, like most lawyers and people that have never built a Security Program are recommending, then good luck with that. NIST provides a lot of great knowledge, ideas and areas of information that is very valuable. My recommendation is to remember that you need to review all the suggested parts you can utilize presented in NIST, and then use a process to only take the right parts to build the right house for your organization. If you need a more process driven approach.let s explore one. 2. ISO 27001: ISMS 3

5 The International Organization for Standardization (ISO) has also published a Security Program Development methodology within its ISO standard. This standard has been updated multiple times with its most recent release in Within this standard, it defines what it calls an Information Security Management System (ISMS). This approach is a set of policies concerned with information security management and is primarily concerned with the most effective manner to manage related security risks in an environment. This approach is more process driven in its suggested approach, which as we mentioned above is very helpful, but this approach is also not all roses. One of the biggest issues is that most of the ISMS driven methodology is to create a mechanism to manage security risk. Risk calculation and management is important to information security and program development, but it gets far too much attention than is really needed in ISMS and really most Security Program Development models. The reason for this is two-fold. The first reason is that many security leaders spend too much time trying to identify a risk model to calculate risk since it is always deemed as so important. During this time, they are not reporting anything to management to help make informed business decisions. So instead of getting at least some good information to make informed business decisions, they get nothing while waiting for perfectly risk calculated information. The second issue, specific to ISMS and risk management is that in the ISO model the overall objective is to get ISO certified. As a result of this, the framework is more aligned to that goal and not necessarily the objectives of your business. This can lead to an implementation that may be really secure, but too intrusive and heavy; thus slowing the business and the ability to deliver exceptional patient care. By the way, this risk emphasis is also a big piece of the latest NIST approaches, particularly the most recent, so be aware. So you may be thinking, what the heck, so are you telling me my Security Program does not need to consider risk. Not A risk emphasis is also a big piece of the latest NIST approaches however risk management risk management is not all you need to have a functioning Security Program, and ISMS spends a lot of time here. Making matters even worse in ISO are the underlying controls in the standard. Actually, the majority of standards and controls for ISO 27001, is addressed in ISO These controls are all the parts for your house using our previous analogy. Well in ISO 27002, they are very subjective and high level, which can make them problematic to get consensus in an environment in terms of what is acceptable. Unless you are going for ISO certification, which I often do not recommend from a benefit/resource perspective to achieve, you will not get the necessary clarification and content expertise from certified ISO auditors to move the process along quick enough. So ISO has some very good guidance, but again is not the silver bullet to Security Program Development. In fact, if you only had the two options presented so far, our team generally represents to take the best from both. We call it the ISO/NIST Swirl to Security Program Development, and it is not a bad approach as it provides the specificity from NIST that the lawyers love with the process driven approach of ISO. 4

6 3. Security Program Development Books So we are a bit biased on this one because we have a published book on Security Program Development in The CISO Handbook. We also created a supporting web-site in CISOHandbook.com, which if you search for Security Program Development on Google is the first returned result. With that said, there are a myriad of Security Program Development books on the market. Here are some considerations in using them that may help. They often break down into three types of book: war story books, certification books and process driven approaches. The war story versions are a collection of stories about how to build a Security Program. These are often a waste of time because your situation will be different from each said story in these books, which often leaves your with fear and anxiety and not an approach. The certification books will tell you exactly what a Security Program should be, but will give you no clue how to build one. In that instance, I would go with NIST and save $70 on a book. Finally, there are process driven books. The key to a process driven Security Program Development approach is that it allows you to customize specifically to your environment The CISO Handbook is a process driven approach to building a Security Program. I still stand behind this methodology and process and though published in 2005, we have been implementing this methodology now more than ever. Further, there may be others out there as well that are process driven, that can also get the job done. The key to a process driven Security Program Development approach is that it will allow you to customize specifically to your environment, and will tell you specifically how to do this. This is key and the only way to success; whether you are using The CISO Handbook or another published work. Considerations for Today Lately, the current security landscape, and more specifically the appetite for organizations to want to build a Security Program is truly amazing. When we first published The CISO Handbook in 2005, organizations were simply not ready for many of the concepts about building a custom fit Security Program. Whereas I begged for meetings with management to discuss building a Security Program even as early as two years ago, now they can t schedule meetings quick enough, or make the necessary investments quick enough to get the program started. That is great if that program is being developed by someone who knows what they are doing. However, I often tell management that a large investment in security, without a sound approach for using it, is 5

7 going to lead to a false sense of security, and actually a less secure environment than spending no money at all. So what to do? Steps for Getting a Security Program going today If you are charged with getting a formal Security Program going today for your organization, here is what I recommend to get you started. Step 1: Understand your options: There are a myriad of approaches in the industry, you just have to understand them and then use this understanding to shape your program. Step 2: Define your functional requirements: What does your program need to do for your organization? A healthy Security Program must have processes to do the following four functional things. They include: 1. Define a standard benchmark: For your organization, a Security Program has to define what the appropriate level of security is that the business must align to. This might be as defined in NIST, ISO, or a custom flavor of standards. None of these are wrong, simply that your Security Program must have a way of defining them and then letting your organization know what they are. What does this look like when done right? When you have established an effective benchmark, your Security Program will have a: a. Defined Program Charter- This ratified charter will illustrate the strategy, mission and mandate, as well as associated roles and responsibilities for your program. A successful Security Program includes: 1. Establishing a benchmark 2. Ability to measure against that benchmark 3. Report findings to management 4. Implement decisions made by management b. Security Policies, Standards, & Guidelines: You will have a retrofitted suite of policies, standards, and associated guidelines that align to your defined program charter. Integrated guidance from NIST or ISO, or anything else should be done here and should be done across all of your documentation. c. Defined Security Processes: Any security process or service that your Security Program performs should be defined and documented in a repeatable process. 2. An ability to measure your environment against your defined benchmark: Once you define your benchmark, you have to institute the mechanism to measure your organization against this benchmark. What does this look like when done right? 6

8 7 a. Establish Risk Management Architecture: Risk management architecture defines all of the areas in which your Security Program must measure issues against your benchmark. In healthcare organizations, this generally includes: i. A HIPAA risk analysis ii. On projects iii. On business associates iv. On systems v. Across hospitals or business units b. Documentation of Each Risk Processes For each risk area in your architecture, you must define and document the process so it is repeatable. This is also where you decide the type of risk methodology you will use per risk area. Don t let great be the enemy of good It is better to report early and often as possible on the current state of security then to do nothing at all here, you will be better served to spend more of your time on clearly defining all of the steps in the process and each interaction with the business. Be aware that most consultants will actually give you exactly the opposite advice. I would advise you to ask them how many risk management programs they have built that are still running a year later in that model. 3. Present the gaps to your benchmark to management and make them DECIDE on what to do: A healthy Security Program will always be able to collect security related information and gaps and present them to management so that they can make informed business decisions. It s important to note that this decision might be to do nothing at all. What does this look like when done right? a. Defined Reporting Architecture: You should have dashboards and reports that provide information on the current state. The number one question I get is what if we don t have any information or measurement ability created. Awesome, in that instance, I provide them the dashboards with the measurement areas I will cover, and I put in bold letters, Building capability to capture this information, then I report on status on building those processes and capabilities. Never be afraid to report current state, and do it early and often. As important, as you improve the environment, report every advancement. If you need a decision from management, tell the story of what you need management to do and put the accountability on them to make a decision. I spend 70% of my time building a reporting system and this infrastructure so I can clearly tell the story of security and the organization. Yes, 70%...not a typo. b. Accountability is shifted to Senior Leadership: When you do a. above right, you will never be accountable for a security breach or error, even if you have major deficiencies in your program. It is a great feeling when it happens and you will know exactly when you get there.

9 c. Established Budget: You will know exactly how much money you need to correct your program and what to do with that money for the next 3 years. 4. Implement Management Decisions: Once a decision has been made, a healthy Security Program can implement the corrective actions as effectively as possible with a repeatable process. What does this look like when done right? a. Security Program Management You will have a defined process for management of remediation projects in your program. You will either have program managers on your team or you will directly integrate a team of managed service consultants into the overall project management at your organization b. Proactive versus Reactive You will feel like you are not thrashing but instead making forward progress. IT CAN HAPPEN You might have others and that is fine, but make sure to clearly define them so you know the house you need to build. By the way, if you decide to read The CISO Handbook, Chapter 1 presents some good additional tips on identifying functional requirements for your program. Step 3: Build your Program: Once you have your functional requirements, the rest is easy. Take this information and go back and select the bits and pieces from the frameworks that will give you the right walls and windows for your custom house, and go and implement it. Summary In summary, I often tell people lately that if I was to write another CISO handbook, it would be about 40 pages and would spend 10 pages on how to attain the four functional requirements designed in Step 2 above. As you read that you may say to yourself that is easy, and why is everyone making such a hubbub about all the Security Program Development stuff. In reality, it is easy if you take a systematic and methodical approach to developing your requirements and then building the right custom fit. However, most organizations are not taking this approach and are still trying to solve these issues with technical solutions or one size fit s all snap in solutions. Like anything in life, take the time to build it right, and you and your organization will be handsomely rewarded. 8