http://en.wikipedia.org/wiki/Computer_security_conference

 
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:

1. Technical Security Testing
2. 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:

1. Excel based checklist format which can be auto compared against a configured baseline
2. 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.

http://mcaf.ee/cryptolaw

How about trying to figure out all those privacy laws for DLP?  Here is another map by Simon Hunt for detailing the major international DLP related privacy laws.

http://mcaf.ee/dlplaws

Take a look at the DLP map below.

It seems  this question has been asked a 100 times yet the other day I was typing up the same answers again because for some reason there was no write up.

This is generic, but hopefully it saves us all time in the future. 

Risks:

Basically there are two key risks.

1. There is no guarantee systems won’t have some type of denial of service.

This is typically a result of having older legacy systems or custom applications, which are taken offline by an automated vulnerability scanner or over abuse by the attacker.

 2. Bandwidth or system utilization may be increased thus resulting in performance loss.

Based on the amount of the automated scanning, the size of the network pipes (both scanning and target), and the number of open ports on a particular system it is possible to overwhelm a service or medium resulting in a performance loss.

Mitigating Risks:

To help prevent a denial of service many approaches can be taken.  Here are some examples.

1. Exclude legacy systems from automated testing. To ensure security perform manual testing of excluded items.

2. Exclude custom applications from automated testing. To ensure security perform manual testing of excluded applications.

3. Perform testing of critical systems during off hours.  Critical systems can be scheduled for testing during low volume business or off business hours.

4. Perform testing in a phased manner starting with user acceptance testing (UAT) environments to ensure the actual tests do not affect particular systems or networks.  Once UAT is complete then begin testing on production environments.

5. Setup monitoring and escalation procedures prior to testing.  Ensure fault management is in place to ensure systems send alerts when they go down.  Ensure proper phone numbers and other contact information is defined to immediately investigate and restore services in the event of a problem.  Escalation procedures should include contact information for the person performing the testing to immediately stop all testing if required.

To help prevent bandwidth issues automated testing can be throttled back to use less bandwidth.  Also the number of ports can be reduced if there is a concern for overloading a particular group of systems.  Usually it is recommended to test the UAT environment instead of reducing the number of ports because certain vulnerabilities may be missed.

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 baselined 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.).

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.

1. Many assessors are using older versions of the SIG and still have not adopted 4.2.
2. Product vendors have incorporated many of the features and appear to be pushing the solution the most.
3. 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.
4. 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.
5. 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?

For those that have little or no knowledge in this area I suggest you review the Security Task Force documentation and the Educause updates located here:

Educause Information Security Governance Assessment Tool

For an open source program I would like to build of the current work, but also provide a lot more emphasis on the organizational charts and the roles and responsibilities.  If your interested please let me know and we can get everyone together and create an updated model for multiple industries.

Blog Post:

• http://risktical.com/2009/03/16/application-security-risk-assessments/

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.

• http://en.wikipedia.org/wiki/Threat_model
• http://msdn.microsoft.com/en-us/library/ms978516.aspx

Strategic Approach

From a managerial risk assessment approach I would take a different view using a strategic NIST/OCTAVE approach.

1. What are the assets? (i.e. information, applications, hardware, etc.)
2. What are the threats? (i.e. data contamination, malicious code, equipment failure, etc.)
3. 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 role 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.

What is required for web app test?  Is it authenticated? Is it just a scan?  Is it just my external environment?  Is it only my card holder systems?

I know the council is trying to do their best with outlining the standards but their still is a serious lack of consistency across QSA’s and organizations.  I found this so frustrating that I developed the cartoon below to represent my opinion.

Basically Mr. CEO here is not meeting PCI compliance and his QSA’s are all telling him something different.  Even better is the new standards and enforcement that all the QSA’s themselves are trying to understand?  Will any big enterprise be able to make compliance?

While visiting this site please check out the new IS Management page and contribute to the voting polls.

• http://infosecalways.com/is-management-polls/

If you would like to see new or different polls added let me know.