Risk is something we deal with on a daily basis. Living in New Jersey and having the occasional storm, I’ve recently performed my own risk assessment determining the value of certain assets and activities and made a decision on what I was willing to spend to reduce risk to what I perceived as an acceptable level. Big pine trees in front of my house weren’t in good shape, so I cut them down which was a good plan given the winds we had. Having a battery backup to let me open my garage doors was also a seemingly good idea because they did last for some of the four day blackout I experienced during Hurricane Sandy, but not testing the manual opening of the doors after I had my garage fixed up and my driveway repaved was a bad part of my plan. Not spending the money buying a gas generator, well I was cold, but I would not have been able to refill my supply of gas if I had one without keeping the equivalent of a small bomb in or near my house in terms of all the gasoline I would need to keep to have the generator run for more than a few days. Cold I can deal with. Death from fire, not my favorite scenario.
My management of risk was a rather simple case. Sure, in my revised business continuity plan for my home, I’ll make sure that I have more D cell batteries, have my garage door adjusted so it opens manually again, more food I can heat on a stove and that doesn’t rely on refrigeration, and finally I’ll consider a whole house gas generator that uses natural gas, which has always been available to power critical systems like the sump pump in my basement. What if, however, I was a really large business? One with lots of components and interdependencies that require a tight integration in order to succeed? How and where can a large volume of information necessary to management, business continuity, and disaster recovery be correlated and communicated to those individuals who, because of their roles and responsibilities, need to make the critical decisions regarding the management of risk?
Business continuity risk management is only one aspect of Governance, Risk, and Compliance. A really good list of regulations can be found here; management that needs to be managed by businesses and other types of organizations. Other aspects of a GRC program, which is mandated by numerous security standards such as ISO 27002, include;
Policy Management – Which will be the basis of the procedures, guidelines, and standards established to support policy.
Compliance Management – Mapping procedures, guidelines, and standards to existing rules and regulations such as HIPAA and identifying gaps that need remediation.
Audit Management – The ability to produce the necessary evidence to satisfy an examination of the effectiveness of controls approved and communicated by senior management.
Enterprise Management – Establishment of clearly defined areas of responsibilities.
Incident Management – The consolidation of various reporting mechanisms to better be able to identify threats and develop strategies to deal with Advanced Persistent Threats.
Threat Management – To be better able to quantify the risk associated with a given asset.
Vendor Management – A means of tracking vendors to ensure compliance to standards mandated by senior management.
Which brings us to the product that is the main focus of this blog post, RSA’s Archer eGRC. RSA’s Archer eGRC solution can be best described as a framework upon which an organization can combine, consolidate, and feed many data sources to produce a collaborative solution. Archer is available as a standalone product or as a SaaS cloud based service. You can buy a solution for say PCI compliance or develop your own. There is an API for data feeds from other products such as Microsoft’s SCOM, and Archer, of course, integrates with other RSA products such as Envision and SecureID.
With proper planning and, more importantly, the firm support of senior management, this technology will make people responsible for the IT assets under their ownership. There is a very active Archer eGRC community and Exchange that shares solutions that may meet your requirements as well as an annual Archer user’s conference. But let us say that, for argument sake, you had a unique system requirement and of course had a development environment to work with given Archer’s ability to export applications. Here are some of the steps you’ll need to consider.
- Define what data needs to be collected. Archer is organized very much like an Excel workbook. Applications are like worksheets. Rows are like a record in a database. Columns perform like fields. Effort here can be reused with an application being a part of many solutions. Something that can also reused is a feature called a Global Values List. Very much like managed metadata in SharePoint, these values can used to limit the data that is placed into a field. This Global Values List can be exported and used organizationally.
- Determine if the values in fields need to be manipulated. Archer fields are just like those in Excel. Data can be converted or used as a trigger for a workflow if the information has been added or changed.
- Establish a control for how an application will be classified as Production, Development, Archived, or Retired. Archer uses a system of on demand licensing so which state an application is important as a naming convention and the solution an application may belong to.
- Enable email flow, spell check, and task management for each application. If an application is layered, it can pass information between layers. You may need to work with your Microsoft Exchange Administrators on this feature set.
- There are reserved field names that are used for System, Basic, and Advanced Fields so documentation and standards are important. Fields can also be used for many other functions such as Audit and Search. You will also need to identify key fields, this is a database after all. Just be careful if you change your mind and delete a field. Depending on the type you can lose all your data.
- You can attach different file types but you will need to decide on the quantity and size of the files you include in an application. You can also include pictures and external links to other resources such as a SharePoint site.
- Identify applications that can feed data into the Archer system and establish the necessary security parameters as well as the types of data that you want to incorporate into the Archer system.
- Establish a communications strategy. Archer has a mechanism for constructing surveys and correlating the results.
- Determine the proper security settings. Archer is going to have a lot of extremely sensitive data in its repository. Access should be on a need to know basis with only senior management having complete visibility.
- Archer can be customized out of the box with many themes to choose from. Your artwork can also incorporated into the overall design.
- Verify your licensing requirements.
- Perform user acceptance testing.
- Test to ensure that your security requirements are met.
- Have senior management communicated the importance of the Archer product to the overall risk management process.
- Plan for training. Without everyone on board it will be difficult to get the full value of the Archer product.
- Incorporate Archer into your existing Disaster Recovery plan.
- Place the product into production using the accepted means of change control.
Have I included every possible step? Probably not. This is a mission critical application, and there will be circumstances where Archer professional services gets involved. What you will get for your efforts at the end is a robust eGRC system that will help you meet the challenges of today’s increasing difficult regulatory environment.
This is the first of a series of articles involving the RSA product line. Future posts will focus on specific Archer eGRC solutions as well as other products in the RSA product line.
RSA Archer Certified Administrator Certification
RSA Archer Administration
RSA Archer Advanced Administration