Rogue Russian entities in the advertising industry take millions and the entire company disappears. Poor security programming techniques from offshore entities expose cross site scripting flaws in 50% of the companies websites. In any event more and more security weakness is exposed by the poor practices associated with a vendor, partner, or other third party business entity. These third party entities and the services they provide can cause great exposure resulting in large scale financial problems to the host organization.
What can be done?
Security of third party entities can be accomplished in many ways, but it has to start with the relationship and contracts in place. Once there is a contract then each practice can be broken down. Third party security assessments typically include two main practices. These are:
- Technical Security Testing
- Checklist Validation Assessments
Technical Security Testing usually involves network vulnerability scanning, penetration testing, application testing, and sometimes security configuration reviews. This approach occurs when a third party is contracted to assess the host organization. This is a third party assessment however this situation addresses contracting a third party to perform the assessment. The other focuses on assessing the host organizations third party service providers, not contracting a third party to perform an assessment.
Checklist validation assessments are commonly used for assessing ones service providers. One of the most common used tools for this practice is supplied online by Shared Assessments. The Shared assessments questionnaire and agreed upon procedures guides are used in many different countries around the world. They are very comprehensive and allow for customization if required. The core components that make this tool fantastic for third party risk assessments are:
- Excel based checklist format which can be auto compared against a configured baseline
- Comprehensive list of standard questions that map to some different compliance regulations
The Shared Assessments program has done a good job explaining the tool use and to avoid repeating the information that is clearly explained online the focus will be to explain leveraging the tool to build a third party assessment function in the organization. Building the third party assessment requires some dedicated resource time for the following responsibilities.
- Determining the assessment schedule and prioritization
- Customizing the questionnaires
- Phone and email follow up to third parties
- Onsite review and validation (if applicable based on the assessment type)
- Providing reports to management and third party entities
- Follow up on remediation efforts
Shared Assessments – Useful
Back in 2009 my blog entry was titled “BITS Shared Assessments – Useful or Not”. After several more years and reviewing hundreds of clients it appears this is now the predominantly used assessment practice. Organizations have used the main content and questions then customized and integrated them into formal programs. I still find the validation component one of the weakest links, but in some cases that also falls on the assessor. To help mitigate the risk organizations should be looking at some kind of technical and checklist testing of their entities. Using both of these will help make up for deficiencies in the checklist based approaches.
I encourage others to comment if they have seen different standards for third party assessment especially those around the checklist and validation approach. As today the Shared Assessments appears to still be the number one choice implemented and used based on my experience with other companies.
This is a topic that has generated a great deal of traffic on the Linkedin “Governance, Risk and Compliance Management (GRC) site. If you are a member I recommend you read through the comments, if not you should consider joining. This is a cross post, slightly modified, of my answer to this question, so forgive the double traffic if you are a member.
I was shocked that no one had mentioned the size and financial ability of the company. So this addresses both small and large corporations with and without financial money allocated to security.
If the company is 300 people and has very little money then usually the starting point is convincing management why money needs to be directed towards an assessment versus actually doing something tangible. Therefore, obtaining management support through some shock and awe factor will help get buy in and then you can do a risk assessment. That assessment should provide a roadmap and serve as the strategic plan.
Now if the company is more mature and financially stable, I agree with several of the current comments, which stated some type of RA framework or COSO control framework. Anyway, the typical starting point is conducting some type of strategic risk assessment. Something reviews all of the organizations assets, the threats, and vulnerabilities. This assessment should help start the program by prioritizing based on risk each security effort. From this assessment one of action items, if it doesn’t already exist, should be to put in a control (ISMS) type framework in place.
Once the prioritized roadmap is created and a control structure is in place then these two items can be put into a baseline and measured over time. Also each control area can have individual metrics. As the risk management program grows the next step will be to build a project or application based risk approach in addition to the strategic risk assessment. This focus of this secondary assessment approach is to rapidly assess projects and determine the level of security review required at the project level. Some projects will require more based on their risk (i.e. type of data, etc.).
What do you think? Is this another useless assessment methodology, great idea, or a platform for vendors to sell products?
I recently went to the 2nd Annual BITs Shared Assessments in Chicago. http://www.sharedassessments.org/
I found the event driven mostly by product vendors, a few assessment firms, and some footprint from the banking industry. During the time of the event and now I was able to deliver an engagement and as a result of the conference and this delivery I have the following comments.
- Many assessors are using older versions of the SIG and still have not adopted 4.2.
- Product vendors have incorporated many of the features and appear to be pushing the solution the most.
- The current AUP and SIG are fairly decent, but the overall solution still needs to mature greatly. I found that several of the AUPs were incorrect or missing. I have yet to consolidate all my comments; however I emailed the main contact number on the site. Currently comments are submitted one by one. I don’t want to enter them one by one, thus, I haven’t submitted as I’m still waiting for a response after several weeks.
- The current scoping and process for delivery is underestimated. My experience shows that you will have to set strict guidelines with the number of follow up conversations and have a cut off for evidence. Otherwise the entity that is assessed will continue to try and justify they have the appropriate controls in place.
- There are plans for mapping to other compliance regulations. There are many more comments I have about this solution, but mostly I’m seeing customers use only the SIG Light or SIG level 2.
I see this as holding a place in the 3rd party assessment realm for an organization. I’m wondering! Is anyone else using the Shared Assessments? What are your thoughts? Will this solution grow and be used like PCI even though it doesn’t have the formal backing like PCI?
I came across an interesting blog about application risk assessment today, so I wanted to highlight some of the different approaches in response.
In the blog Chris’s approach seems somewhat like threat modeling, which is typically used for code reviews. In general he covers a large part of the important content but doesn’t address the real issues of risk – Cost vs Risk. Anyway I hope to address that here and explain the two major methods used extensively. These are threat modeling and the NIST/OCTAVE asset based approach.
Threat Modeling Approach
Threat Modeling is basically the ongoing risk assessment process which covers the entire Software Development Lifecycle.
From a managerial risk assessment approach I would take a different view using a strategic NIST/OCTAVE approach.
What are the assets? (i.e. information, applications, hardware, etc.)
What are the threats? (i.e. data contamination, malicious code, equipment failure, etc.)
What are the vulnerabilities (i.e. no security training for developers, lack of formal SDLC, no development standards, no security requirements, no security testing, etc.)
Within the vulnerabilities I would roll up any identified tactical findings into strategic issues. For example, software code with clear text passwords may result in a poor encryption policy, lack of standard, or a lack of proper classification policy and controls around passwords.
Overall using this strategic approach helps us to determine what assets in the entire application architecture/environment have the highest risk and we can mitigate accordingly. In the long run this approach should save cost. We really wouldn’t want to spend $40,000 dollars on a code review for each application when I know that none of the developers have security training nor do we have secure development standards. This money can be strategically better spent on training since we might have 30 applications across the enterprise. At that point we can then decide to perform a sample checkup and measure the progress to see how we perform both before and after the training. This will be the most cost effective approach and produce metrics that can be delivered to executive management.
For anyone looking to find or understand the main key compliance documents across the following industries, regulations, regions of the world the link below has a good list.
(Link Updated Sept. 2012)
Industries, Regulations, Regions:
- Sarbanes Oxley Guidance
- Banking and Finance Guidance
- NASD NYSE Guidance
- Healthcare and Life Science Guidance
- Energy Guidance
- US Federal Security Guidance
- US Internal Revenue Guidance
- Records Management Guidance
- NIST Guidance
- ISO Guidance
- ITIL Guidance
- US Federal Privacy Guidance
- US State Laws Guidance
- EU Guidance
- UK and Canadian Guidance
- Other European and African Guidance
- Asia and Pacific Rim Guidance
- System Configuration Guidance
Also, some of these are already linked off this site. If anyone is feeling like they have some free time feel free to send me links to the listed documents and I will add them to the Links page.