LESSONS FROM CONDUCTING A SECURITY GAP ANALYSIS

There are many reasons for ensuring that you have a secure information system. It becomes a question of how instead of why. How do you create and maintain a secure system?

I participated in my first security gap analysis project in 2006, blogged it that year, lost that blog, and found my notes again. It was an eye-opening experience especially since it was conducted in one of the largest hospitals—whether public or private—in the country. It serves the second most populous county in the U.S. According to 2006 US Census Bureau estimates, the county had 5.3 million residents—larger than the populations of 29 individual U.S. states or the combined populations of the six smallest US states.

There are many reasons for ensuring that you have a secure information system. It becomes a question of how instead of why. How do you create and maintain a secure system? Starting with what you have, the first step is to create a baseline—a model of your expectations about the security of your information system. If your business belongs to one of several industries that are governed by laws and regulations then you should start with the security requirements of those same laws and regulations.

A hospital, for instance, would be directly governed by the Health Insurance Portability & Accountability Act (HIPAA). It is also subject to other regulations like the eDiscovery rules but we will keep it simple by focusing on HIPAA alone.

The second step is to categorize the sensitivity of your data, identify its source, its location within the system, how its accessed, and who can access it.

Sensitive data can take the form of intellectual property. For a hospital, sensitive data is frequently legally protected. An example is the X-ray images of a patient.

Armed with this information, you can begin your gap analysis. Before this discussion goes further, it must be understood that gap analysis is an ongoing process. The environment is constantly changing. Your information system is constantly changing with it and, naturally, your security gaps are changing as well.

Comparing your actual practices with security requirements will identify the gaps in your system. Once identified, the gaps can be prioritized (by severity, for instance). Then a plan can be created for eliminating (or at least minimizing) those vulnerabilities.

Gap analysis is a specialized form of risk analysis. Risk analysis recognizes the fact that risks are everywhere and that you have limited resources to deal with them. The goal of risk analysis, therefore, is to learn how to deploy your resources in the most effective manner to eliminate or minimize the worst or most likely threats.

It is best to approach gap analysis as a project and like any project, senior management must support it. Security gap analysis must be conducted on a regular basis. It must be thorough and objective. The degree of thoroughness will establish the scope of the analysis. Will the project include physical as well as electronic security? Will it be limited to customer-facing applications?

Objectivity requires a fresh set of eyes. It wouldn’t make sense for an accountant to audit himself. It makes a lot of sense therefore to hire an outside firm to lead the project.

These are the lessons I learned when we conducted a security gap analysis at one of the largest hospitals—whether public or private—in the country.

Our presence was announced with a bang! When you stage a systems break-in, attack the system like a team of hackers would. A team attack is just as likely to happen in real life as a solitary attempt would. The ease and speed of our break-in convinced the hospital’s administration of the risks it faced.

Your project team should have members from different disciplines. I came away convinced that if the core team could only have two groups then the two should be your IT and your HR departments. Why HR? It’s because people will be the primary source of vulnerabilities.

Hospitals are very politicized organizations. In addition to having senior management’s blessing, we created a RACI matrix that was jointly accepted by all department heads.

RACI stands for Responsible-Accountable-Consulted-Informed. A RACI matrix will identify the authority and responsibility of all roles involved in the project. We had determined that our scope was going to be limited to electronic security and to customer-facing applications only. Due to the size of the hospital and the number of applications it ran, our gap analysis focused on the two most heavily implemented applications: lab and accounting.

This was the first gap analysis conducted on this hospital and the spotlight was on it. (And did it ever need it!)

WE ANALYZED THE GAP IN FIVE AREAS

FIRST AREA

AAA – Authorization, Access, and Accounting on an enterprise level. This included single sign-on, a primary aspect of federated identity. Our goal was to standardize the security infrastructure. We discovered numerous instances where Nurse-A could log in at Station-1, stay logged in while logging in again as herself at Station-2, and be granted a different access level.

All current authentication processes were reviewed. Possible vendor solutions were evaluated. A general implementation plan was developed.

SECOND AREA

Awareness. How security-conscious are the employees? Did they know about the different security levels of information?

1. Unclassified
   
2. Classified
   
3. Confidential
   
4. Restricted
   
5. Secret
   
6. Top Secret

Our goal was to heighten the security awareness of workers throughout the organization. Make it clear that this is everyone’s responsibility and request for their cooperation. A regular familiarization course was developed and all employees have to attend it every six months. A hotline was also established.

THIRD AREA

Incident Notification & Response. The security awareness course and the hotline are just two of the responsibilities of a new IT-based group. Our goal was to create a first-response team and proactive overseer of enterprise security. They did not make policy; instead they implemented it. At the same time, they tracked actual user practices, compared it to best practices, and submitted progress reports to the Chief Security Officer (a position that was newly created).

FOURTH AREA

Technical Security. We conducted a comprehensive review of the existing security framework. The framework covered firewalls, DMZs, intrusion detection & prevention tools, and the like. Security logs were audited. Patch management was taken seriously. Password policies were enacted. Our goal was to optimize the hospital’s technical security. These efforts were primarily focused at the hospital’s data center. Technical security briefly touched on Disaster Recovery but DR was going to be a separate project.

FIFTH AREA

Best Practices. Our objective was to train users to work using best practices. This was easier said than done since this was change management and most of the staff were lifers, i.e., employees of long tenure. We had to start over several times. In the end, we learned that the best way to coax them to accept change was to first listen to them. This is the area where our business analysts really proved their worth!

CONCLUSION

Several areas above, e.g., Technical Security and Best Practices, were longer and more difficult than expected. The entire project took eight months—two months past schedule and 40% over budget! The core project team consisted of three full-time members. I was one of them.

Would I consider it successful? Yes. We achieved the project's goals. Were the customers happy? The end-users were. Management was not. From the beginning, we articulated to senior management that they had an unrealistic schedule especially because they were ripping out an old application software system. Delays cost money.

At the project onset, they practiced an all too familiar but ill-advised tactic. They asked us for a "realistic" budget. We were outside consultants. Specifically we were the subcontractors of a (politically-connected) contractor. We used parametric and bottom-up estimates, got the agreement from our contractor, and we jointly submitted it to hospital management.

I remember the incident vividly. We were in the office of the hospital administrator. He glanced at it, asked us a few questions, crossed out our figure, deducted 30%, and wrote that down and signed off beside his scribbled amount. Furthermore, he slashed a month of our projected schedule.

PROJECT MANAGERS NEED BUSINESS ANALYSTS TO SUCCEED. WHY?

I was fortunate to have started as a Business Analyst before becoming a Project Manager. In many ways I think it’s an ideal career path to project management and, eventually, program or portfolio management. In this entry, I explain the reason for that.

Projects are everywhere. We work on them constantly even though we don’t realize it.

Typically, three types are found in anyone’s list of things-to-do. Tasks. Projects. And goals.

Tasks are straightforward activities. Clean the room. Replace the car battery. Walk the dog.

Projects consist of several tasks. Prepare the car for the long trip may consist of tasks like making an appointment with the mechanic, waiting for the mechanic to identify the parts that need to be replaced, tuned up, or repaired, and arranging an alternative means of transportation while the car is being prepared.

Goals are objectives, broadly speaking. Join the family reunion is a goal. Among its projects may be preparing the car for the long trip as well as scheduling time off from work. In this example goal, the explicit objective is to drive a safe and tuned car for the long trip. The idea is to reach the destination safely and minimize the possibility of developing car trouble during the trip.

It’s no different in business. A goal is established and projects emerge to accomplish the goal. Projects, therefore, are essential to the fulfillment of goals and, broadly speaking again, goals are established to either cut costs or increase revenue. All organizations have goals. Therefore, all organizations engage in projects. Projects, therefore, are everywhere. We work on them constantly even while we don't realize it.

ACCELERATION THROUGH TECHNOLOGY

Today, technology has sped up the pace of life. Consequently, competition is more intense. Imagine a company with a better-designed product. It must generate revenue from that product with a sense of urgency. Why? Because it’ll only be a matter of time before competitors introduce their own improved product. The very website that markets the product (technology) is also the window that alerts competitors. There are several ways for competitors to come up with an improved product. For example, it can engineer its own and do so with the same people who created the original. The competitor simply hires the company’s employees. Whether the competitor hires them directly or through a recruiter, technology in the form of email or the mobile phone enables it quickly and discreetly.

This holds true even for a company that possesses a strategic advantage—“strategic” in the sense that its advantage is major or more permanent. Take a company with a grocery store in a better location. Perhaps, it may even be the only grocery in a rural area. The combination of human intelligence augmented by technology—this time for example, in the form of targeted direct mail—can level the field.

MAKING BUSINESS PROCESSES MORE EFFECTIVE

Today, goals tend to revolve around making the organization more competitive. For example, if a hospital can forecast the peak times of its Emergency Department (more commonly known to the public as “ER,” for Emergency Room), then it can schedule its personnel more effectively. Why have four ER personnel during the Tuesday morning shift when it knows that more cases are more likely to arrive that evening? Is it possible to do this? After all, how can it predict the future? Sure, it can and with a high level of accuracy. The majority of hospitals have never applied the statistical principles of forecasting that airlines use. Even long-established methods of manufacturing (like quality control) can contribute to the forecasting.

More effective processes create cost savings, a better bottom line, and a competitive advantage. Most goals, therefore, revolve around improving these processes—re-engineering them to make them more efficient and, ultimately, more effective.

EFFICIENT & EFFECTIVE

What’s the difference between efficient and effective? The best definitions I’ve encountered are succinct: efficient means doing things right (the first time) but effective means doing the right things.

To continue, business processes are frequently a combination of workflows and IT processes. A workflow combines human action and practices. When a patient arrives at the ER, the patient’s information must be collected. Will the workflow consist of the admission clerk writing the information on a paper form or keying it into a computer?

Today, it’s mostly the latter. Data and information, therefore, are two critical components of business processes. Many projects, therefore, are IT-based.

DATA & INFORMATION

What’s the difference between data and information? This is the distinction I prefer: data becomes information when data is put in context. The numeral 2, for example, is data. However, if 1 is the code for male and 2 is the code for female, then the numeral 2, in that context, becomes information.

To continue, projects, especially ones that tinker with processes, must be carefully implemented. An important factor that improves the success rate of projects is careful preparation. In particular, the early phases of any project must be focused on understanding the requirements of the project. Requirements must be clarified in order to ensure that the objective of the project is satisfactorily met.

If the project created an accurate ER forecasting system but the project manager (and his sponsors) failed to ensure the availability of the right combination of medical staff, then the hospital may even be worse off than before. A similar situation may arise if the hospital did not adjust its resources to equip the ER with enough equipment to handle the forecast.

THE COLLABORATION OF THE PROJECT MANAGER AND BUSINESS ANALYST

Successfully implementing a project requires two persons. First is the Project Manager (PM). He focuses on leading the project to its successful completion. However, to ensure that the project’s objective delivers the intended benefit, another person is necessary. This is the Business Analyst (BA). The BA is concerned with managing the business requirements of the project. The business requirements refer to the business benefit of the objective (e.g., cost savings) and to the things necessary to achieve that objective. Poor business analysis leads to inadequate information that, in turn, generates incorrect requirements. Incorrect requirements lead to inaccurate estimates and any project that begins with an inaccurate baseline will likely fall short of its objective.

A project’s requirements span the range from understanding the business case to identifying the processes that will be affected to defining the exact outcome. The last may seem strange but it’s critical to know how the outcome will look like. Will the project objective be met when the forecasting system is in place? Or will it be considered met after the budget has been changed and approved?

Now, isn’t it obvious that a project’s requirements must be captured and fully understood before the project plan is finalized?

The BA has the responsibility of bridging the gap between the user community and the IT personnel. From the former, the BA uncovers their requirements. From the latter, the BA collaborates to design the solution.

In some ways, the BA is more essential to a project’s success than the IT experts. Technical skills can be outsourced but the BA and his skills need to be present in order to uncover the project’s requirements. With that in mind, doesn’t it appear that business analysis should not be treated as subordinate to technical expertise? Many IT experts do not possess the temperament or personality to gather, understand, and analyze business requirements from the user community. Fewer still are able to create realistic solutions that address these requirements since many solutions are a combination of technology and processes.

Many processes involve workflows and, as mentioned earlier, people are typically involved in workflows. Persuading people to change their habits is not an easy task. Changing work habits is especially difficult since workers naturally do not want to be blamed for undesirable results. So delicate and important is this that change, in today’s environment, has evolved into its own management discipline—called, appropriately enough, change management.

Many projects that fail share this condition. The project is initiated, planned, and implemented before the project team and project stakeholders understand the business requirements clearly. This is due, in large part, to our natural belief in technical wizardry and our impatience in old-fashioned techniques of surveys and brainstorming. Too often, the latter activities are rushed. Capable PMs that take over failing projects will realize the problem and force mid-course corrections. Unfortunately, even if the project eventually meets its objective, it will invariably have exceeded its original budget and schedule.

A BA makes valuable contributions in numerous ways. He has created sub-objectives from the primary objective based on a clear understanding of the business case for the project. He has gathered the requirements that the project must meet. He has analyzed these requirements with respect to risk, resources, and time. He has shared these with the PM and project team and assisted them with devise the solution.

This blogpost, I trust, should have made it clear why I think that Project Managers need Business Analysts to succeed.

Business Analysts have a professional organization of their own, like Project Managers. BAs have the International Institute of Business Analysis. PMs have the Project Management Institute.


Link to this blogpost