• United States



A Day in the Life of a Risk Analyst – A Short Story (based upon a true story)

Mar 27, 200913 mins
Business ContinuityData and Information SecurityIdentity Management Solutions

This is the short story version and daily flow of a risk analyst at most any company as he/she goes through a standard risk assessment for a system within most any company's internal infrastructure. There is much more that could be added but in the essence of time, here is the short story version.

I have just been notified that we have four new systems to review at the Initial Project Review (IPR). I will take the first one called LegalSaaS. Looks like the Jim Abrams is project manager but I need to find out who the business owner is for this project. Nancy Smith in finance is the business owner. Time to talk with Nancy and review the risk questionnaire. This questionnaire tries to get the business owner to define the value of the system to most any company. This helps us determine at least initially, the level of effort we need to expend, the depth of the assessment since we will apply the proper level of resources based upon the criticality of the system and/or information. Our motto is "Don't use a sledgehammer to push in a tack." The composite score for LegalSaaS is 88 which places this project in the High Risk category. Looks like this one will require some significant attention and resources, at least at this point in the effort.

The next step we go through is based upon our RIIOT method. The RIIOT method is as follows:

RIIOT (Thank you Doug Landoll)

The RIIOT method (Review, Interview, Identify, Observe and Test) comprises five different approaches to data gathering and can be applied to the administrative, physical and technical areas when performing a Risk Assessment.

*R*eview Documents – The risk assessment team reviews documents regarding the rules, configurations, layouts, architectures, and other elements of security controls All available and relevant documents may be reviewed and can include policies, procedures, network diagrams, architectural stacks, backup schedules, site physical layouts and security awareness training packages and slides.

The problem I have here is that I do not know where to find the documents. I do not know if what the review process has been; who owns them; how many changes or iterations there have been or if they are lacking. I do not even know the approval process or how the documents are governed. In addition, if the documents are sensitive, I need to have security on these documents for add, change, delete, viewing, if they can or cannot be sent out of the most any company network, or if someone tries to send them out, I can prevent this from happening and track this. 

*I*nterview Key Personnel. The risk assessment team interviews key personnel to determine their ability to perform their duties (as stated in policies), their implementation of duties not stated in policies, and observations or concerns they have with current security controls.

The documentation should define key personnel and the process flow (governance) for the policy review process. I need to map the conversations with key personnel to the documents reviewed to ensure awareness of the documents and track what was said in the interviews. Roles and responsibilities need to be clearly defined here as well as their understanding of the controls as per the documentation as well as any other controls not documented. 

*I*dentify the Impact of Security Controls – The security risk assessment team members inspect specific implemented security controls such as visitor control, configuration files, smoke detectors, and incident response handling. These controls can be inspected against industry standards, specific checklists of common vulnerabilities, or by using experience and judgments.

The documentation has been great in providing information but I have found that much of the documentation is incomplete and since some of LegalSaaS is new, it has not as yet been created. In addition, there have been many changes to the technology over the past year that has not been identified. I need to define my 'Enclave Boundaries'  so I know exactly what it is I am assessing and to get a handle on the interfaces and interactions of all the different hardware and software stacks involved in the system.

 This will help identify all technical controls and direct me towards process and procedural controls as well as policies. How do I go about discovering what I have out there that is the system? Can I tell where data starts at its inception and when/if it leaves our boundaries and lightens the risk load by transferring some of the risk to a third party? 

They said there is an ASP involved. I will need to look further.   Before I forget, I should take a look at any IT or security incidents related to the existing system and audit findings that may be in place. The current ticket tracking system is not ours but I will mine that for data on potential issues that will give me a view on whether there have been control issues with the system. If I get a solid read on all the devices or individual assets associated with the current system, I can start checking on their vulnerabilities and configurations. I will have to use a third party scanning tool but I can feed this information into our SIEM for correlation. 

Hey, once I get all assets associated with the system, I can create correlations within the SIEM that provide control status as I feed log files and third party vulnerability scan information into the system. Sure wish I could control the configurations aligning them to an industry standard like the NSA guidelines ( I think I can do that with network devices but the infrastructure I will have to monitor after the fact. Once I get the full read on all assets, I need to classify them per the system classification and identify them in our incident, DR, and BCP efforts for what they are.

 I should also ensure that the data is stored on the proper devices based upon its sensitivity, properly replicated and virtualized so I have redundancy and resiliency. The data when backed up to tape must be encrypted as well based upon the classification. I sure do not want this data to get out and old versions need to be properly destroyed. I will take a look at what we have for that as well. I want to make sure that any hardware is properly wiped before destruction. That brings me to another potential problem. What if we are placed under a legal hold and eDiscovery rules? Heck, I need to address this with the business as well taking a look at how I store and maintain records.  I will also assign a higher priority to any incidents related to these assets and this system so it is addressed accordingly. One more thing. I have not even looked at access management solutions as yet. Should I use two-factor for this? Maybe for external or remote access into the system. Looks like the business wants that as well.

*O*bserve Personnel Behavior – The risk assessment team members will observe the behavior of users, the security protective force, visitors, and others during the course of the assessment. These observations can provide keen insight into the effectiveness of the security controls in place.

Observing behavior can be fun but this is serious stuff. Now that I have the documents reviewed and key personnel interviewed, I need to see if they actually follow the policies and procedures in place. Surveillance using CCTV and other tools are not really appropriate for this but I could use DLP and SIEM solutions to watch data flows and check configurations to ensure proper standard are in place. That is a method of observation. Otherwise, I will need to sit in with them as they go through their daily operational activities. I am not sure what other solutions we may have that could help here. I will need to talk to someone in product management. I really wish I had more than just the list of all the products we have. What would be useful is a catalog of controls along the lines of primary, compensating, preventive, detective, software, hardware as well as process and procedure. This would certainly help in my being able to compare this to what is in place and based upon the value of the system to the business as well as the sensitivity of the info, apply the controls necessary (remembering our slogan about the sledgehammer - I don't want to cost the business more than is necessary). Being able to select from an ala carte menu of controls like say, two from column A and one from both B and C may be of great help!

*T*est Security Controls – The risk assessment team members will test specific security controls such as firewalls, servers, open door alarms and motion sensors. Almost all security risk assessment methods currently account for this approach. Testing involves the use of vulnerability scanners for logical controls, application scanners, and also specific methods for physical controls such as the shuffle test for motion sensors.

Testing controls is the validation I need now that I have the controls cataloged, the enclave boundaries defined, and the documentation together. I will use some third party tools to test the code, test the infrastructure and then analyze the results. I will rerun the discovery and configuration tools to validate that nothing has changed (hopefully). I think there needs to be some training of IT staff as well as the new tools brought in are not well known here. I will store the test results in a central location and communicate out on the overall status in my final risk assessment document. I will need to pretty much re-access all the pieces (technologies) I have in place and validate that all controls are working as billed! I sure wish someone out there had these solutions under one umbrella. I really don't like having 35 different vendors to deal with; the operational cost model is too high; my staff are jacks of all trades and masters of none; I look at multiple different consoles and have to support multiple different backend databases and agents; this really is costing me too much and vendor management is not happy with the number of vendors since it impacts them as well. Sure hope the business does not hit me on this. 

Now that I have all this completed, I will compare the data against the regulations and associated statutes to ensure I do not have any risks that are unacceptable. If I do, I need to communicate this and write a risk letter that follows our governance model. Below is some of what is in place and some of what is proposed. I will need to get this into process flow diagrams so I can build this workflow into the tools I have. There is a lot there but this is core to the GRC program I am looking to mature further than it is today.  

In the mean time, I need to publish the results; publish the new policies and procedures; and make all aware of the changes to the environment. I am also going to have to engage the folks to add this to the DR and BCP efforts for some sand table exercises.   I need to get the word out!

I guess what I have really discovered is that the company security posture is worse than I thought. In fact, I don't believe we can even rate it at this point. Seems like it falls into a few different areas:

  • We don't know what we don't know
  • We know of some things we don't know
  • The company really seems like it doesn't want to know

Here are some of the warning signs I discovered:

  • Very little documentation.
  • No version control of the documentation that was found.
  • No data classification on the documents.
  • I kept asking for the business owner and kept getting the PM.
  • No ownership defined or last modification information.
  • The people interviewed were aware of some of the documentation.
  • The people interviewed could not identify key controls that were supposed to be theirs.
  • I interviewed some of the wrong people since no one knew who was responsible.
  • Roles and responsibilities were not clearly defined or articulated.
  • The system architects have not defined what the system actually is. In fact, we are still arguing over the definitions for system, application and tool. They don't know what enclave boundaries are and they really have no idea on the data flow, software and hardware stacks, interfaces between software and various stacks and applications within the system.
  • Assets for the system have not been defined.
  • Unclear who is responsible for what.
  • The project manager believes we are in good shape and that there are no issues even though I have already used up the 40 hours (they assigned me) to perform the assessment.
  • Lessons that are learned are not built into the system
  • The software scans found many defects / errors that were deemed acceptable.
  • Configurations are not documented much less standardized.
  • No one has run any vulnerability scans on the shared devices.
  • Sensitive data is not being encrypted on tapes.
  • No one is examining the need to triple wipe drives that contain sensitive data and are no longer needed.
  • There are no eDiscovery or plans to address a legal hold.
  • The ASP is already contracted with us but no one from security was involved in the contract review and no one knows or has assessed their security posture.
  • There is not centralized list of in house products.
  • There is no catalog of controls of any type available.
  • Any controls that are in place have not been validated to determine at what level of effectiveness they are working!
  • We have too many damn vendors to work with and nothing works together.
  • DR and BCP were not considered for this (much less for several of the other projects).
  • The things I found are push aside and I am asked to be quiet - must be a culture of silence.
  • Policies and Procedures are confusing, complex and contradictory.
  • Organizational barriers prevent effective communication to the business owners on the risks to their data.
  • No one wanted to establish metrics of any type for measurement after the system goes live.

Follow me on Twitter  –