IA Awareness Program development simulation based on the NIST 800-50

Assume you just been hired as a Chief Security Officer for a major financial institution.  (congratulations) This financial giant has offices all over the globe and is involved in multiple types of businesses.  Your first order of business is to develop an IA awareness training program.  (The human factor is the weakest link in a security program, so you’ve decided to address this first).

How are you going to do it?  What is the best way to maintain budget, coverage, and integrity (i.e. not get fired for making horrible decisions)

NIST has developed guidance on approaching this very problem.

The three models outlined by the NIST 800-50 are:

–Centralized – This model gives all responsibility for the program development and budget to a central authority.  Determination of a programs needs, content, and dissemination are all determined by the central authority.  Organizational units may be responsible for executing on the plan at the business unit level, but the guidance would come down from the central authority.

This model works great for smaller organizations and/or organization’s that have tightly aligned missions.  Additionally, because so much responsibility is given to a central authority, that office must have the in-depth expertise in order to succeed in the function.

–Partially Decentralized – This model still has a central authority, but the responsibilities of this office differ from the centralized model.  The central authority under this model determines strategy, policy, and budget for the business units.  It is the business unit’s responsibility to determine how the budget will be allocated, all aspects of the training materials, and deployment.  Typically the central authority would require metrics from the business units to determine effectiveness and compliance with the program.

This model works best for larger organizations over a wide geographic area.  Additionally, this model is suited well for organizations that have multiple business units with disparate missions.  By allowing the organization to develop the training materials and deployment strategy, the program can be best assimilated into the organization based each unit’s unique situation.

–Decentralized – This model has a central authority with the responsibility of issuing broad policy regarding the expectations of a security program.  Each organizational unit is responsible for executing an information security awareness program on their own.  A major benefit of this model is the needs assessment is conducted by the organizational unit that fully understands the needs and situation of their particular “world”.

This model is best for organizations that are highly decentralized with general responsibilities assigned by headquarters.  The department of defense comes to mind as a an excellent example of an organization that leverages this approach.

As the ISO for U.S. Bank, I would move forward with the partially decentralized model for my information security awareness program.  The U.S. Bank is a large, geographically disbursed organization with its business units having unique missions.  These conditions are ideal for the partially decentralized model.  The strategy and overarching policy would come from the CISO office, but it would be each business unit’s responsibility to develop training materials and deployment plans.

This approach affords the flexibility required to deliver value-add information security awareness.  Different regions have unique cultures, customs and risks.  The organization leaders would be better positioned to develop materials that will address the needs of the organization and improve the security posture overall.  Additionally, the CISO is not in a position to be able to effectively determine the needs and approach for the training materials and deployments.  That is another convincing reason why the partially decentralized approach, leveraging the organizational unit’s leaders, is the optimal model to select.

I would suggest, depending on the feedback, metrics and quality of the information security program, migrating to a decentralized model within 5-7 years.  Hopefully, the program would have matured by this point and would be in a sustainability phase.  The organizational leaders would understand the ‘tone-at-the-top’ based on the programs history and would be enabled and equipped to successfully run their own programs.  The organizational leaders would be responsible for providing metrics to senior management to ensure visibility and oversight is taking place.

NIST 800-50 Building an Information Technology Security Awareness and Training Program.
http://csrc.nist.gov/publications/nistpubs/800-50/NIST-SP800-50.pdf

Importance of metrics for a successful information security program

The recognition of information assurance and information security has transitioned from an ancillary activity assigned to the IT department to a required business function with its own recognized cross-domain impact across an organization.  This can be seen flagrantly in the evolution of the NIST 800-53, where security has gone from a concept derived from the system development lifecycle to an enterprise-wide risk management concern (complete with a risk executive (function)).

The recognized importance of security and value now brings it under the purview of senior management.  Senior management requires dashboard level views of business functions to make strategic and tactical decisions.  This need is exactly why security metrics are critical to the success of an organizations information security plan.

Metrics enable a business to understand the condition and direction their security posture is and is heading, respectively.  Based on the insight aggregated metrics can provide, management can refine a process or procedure to be more effective, cost less or coupled with other redundant processes.

Per John McCumber’s methodology on implementing effective IT risk management, human factors are one third of the targeted areas to address.  Metrics are reportable, discussable, and often require human involvement for reporting and disseminating.  This provides direct awareness and involvement of the human factor elements of a business increasing the indirect value of the metrics.

I do not agree with a simplistic view of reported vulnerabilities found on an information system is a good security metric.  An information system with 100 low risk, low probability vulnerabilities is, in my opinion, more secure than an information system with 1 high risk, high probability vulnerability.

I would suggest to an organization that a security framework be implemented to effectively address their information security needs in an organized manner.  ISO 27001, CobIT, and NIST are all mature, proven security frameworks to select from.  An organization that implements a framework receives the ability to effectively capture metrics on the implementation and compliance with the security framework.  This gets to birds with one stone; a proven security framework and the ability to assess compliance, which yields metrics.

Bibliography

IT Governance Institute. (2007). CobIT 4.1. Rolling Meadows, IL: IT Governance Institute.

McCumber, J. (2005). Assessing and managing security Risk in IT Systems; a structured methodology. Florida: Auerbach Publications.

National Institute of Standards and Technology. (2007, December). NIST Publications. Retrieved November 19, 2009, from National Institute of Standards and Technology: http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf

Payne, S. (2006, June 19). A Guide to Security Metrics. Retrieved February 6, 2010, from SANS Institute Infosec Reading Room: http://www.sans.org/reading_room/whitepapers/auditing/a_guide_to_security_metrics_55?show=55.php&cat=auditing

What would you look for in an organization’s ability to respond to a security incident?

The initial item I would look for would be the Incident Response Plan (IRP).  This policy document would provide the insight to determine if the organization is adequately prepared to handle all facets of an incident.  The elements within the IRP I would look for include:

1. Senior Management’s commitment – Any plan, especially related to organizational information security must have senior leadership’s public support and commitment.  Without a strong tone-at-the-top the organizational body will not put weight into the IRP, resulting in false metrics and poorly handled incidents.
2. Priority or severity ratings for incidents – Different incidents require a different level of effort and a different window of resolution to address.  While not every incident can be predicted, categories can be developed and thought can be given ahead of time to address the severity and impact an incident would have on an organization.  As new, uncategorized incidents take place the IRP can be updated accordingly.  These categories will give the incident response team (IRT) the ability to triage incidents in the event of multiple incidents.
3. Defined communication plan – Communication is critical to successfully execute an incident response.  The IRP should clearly define who is involved in responding to an incident, who should contact who for actionable items, when certain parties should be contacted (i.e. legal, PR, law enforcement) and how to contact each individual and entity potentially involved.  The communication plan should be a living document that is updated as human resources and business relationships change.  Multiple contact vectors for critical individuals should be made available and 3^rd party vendors should be brought into the fold on what individuals have the authority to represent the organization.
4. Defined reporting and forms – Incidents are often swift and require immediate action to return to normal operating conditions, but reporting and standardized forms should be leveraged in order to provide a consistent and repeatable approach to incident handling and more importantly a means to track metrics.  Bringing personnel up-to-speed on the IRT is accelerated with a defined approach on how the work is captured and reported.  Additionally, by providing a standardized look and feel to how incidents are documented, senior management is enabled to make better decisions in shorter time.
5. Roles and responsibilities – This is critical to an effective IRP.  The roles and responsibilities of the incident response team and tangential stakeholders are important to define prior to being “in the heat of the moment”.  By logically assessing and determining what the roles and responsibilities are for the team members, a level head can be maintained during an incident response.  This component ensures that responsibilities are not overlooked and missed and that multiple people are redundantly performing the same role.
6. Third-party consideration – Clearly depicted in the iPremier academic exercise this semester, it is important to ensure that any third party vendors an organization deals with and relies upon is aware of the key stakeholders from the IRT.  Any non-disclosure agreements or access requirements should be vetted and approved long in advance to eliminate any administrative obstacles during an incident.  Additionally it would add value to an organization’s IRP to work with their third parties to understand how incident response is handled at their organization and identify any overlap that could be leveraged to benefit both organizations.
7. External entity relations (Meida/Law enforcement) – Some incidents will require additional action outside of the initial incident response.  The IRP should identity the communication strategy and individual with authority to contact external entities and bring them into scope of the incident.  Without clearly defining an approach, external entities may be brought in unnecessarily or the incident may be presented inaccurately.  This could lead to negative public relations, loss of reputation or lack of confidence in the market.
8. Team model and members – Outlined above by the communication plan and the roles and responsibilities, the team model and actual members of the team must be identified in the IRP.  These individuals are empowered by the organization to act with authority to professionally and appropriately respond to an incident in a methodical and controlled manner.  It is critical that the IRP be maintained as a living document and updated as frequently as required.  The document is worthless if the data contained within it is out-dated and irrelevant.

Additionally I would request to see previous incident reports and any metrics the organization may have related to incident response.  This historical data can assist me in determining if the organization is following their IRP and how well the organization is performing in handling incidents.  I would also like to research whether recurring incidents are being brought to management’s attention for consideration and policy/procedure refinement.

US Cyber Domain Security Posture

Relative to the article “U.S. would lose a cyber war, former intell chief warns” found Government Computer News’s website à http://gcn.com/articles/2010/02/24/web-mcconnell-cyber-threat.aspx?s=gcndaily_250210

The thesis of McConnell’s position is ““We’re [sic U.S.] the most vulnerable, we’re the most connected, we have the most to lose, so if we went to war today in a cyber war we would lose.”  This projects that the U.S. would be crippled and that there are no risk mitigating controls in place for critical infrastructure facilities and architecture.  The quantification of “lose” in this statement must be defined in order to understand what losing is.

Unfortunately I would agree the U.S. critical infrastructure sectors are not mitigating risk to an acceptable level.  In addition, it seems these sectors have no motivation or incentive to take cyber security seriously.  Based on a report in 2009 from the US GAO, Department of Homeland Security released guidance in 2006 for the sectors to develop a plan for ‘how cybersecurity will be accomplished’.  None of the sectors had developed a plan that addressed all the cyber security criteria that was identified.  Identifying this deficiency, DHS requested the sectors update the plans accordingly.  As of the report publication date (Sept 2009) only 3 of the 17 sectors had bothered to update their plans relative to the cyber security criteria.

McConnell’s statement that a catastrophic event will need to occur before comprehensive security controls are put in place is sadly more truth than fiction.  I would disagree with the extremes with which he discusses the results of an event (a return to a Cold-War state of the union), and the solution (re-engineering of the internet to make attribution, geolocation, intelligence analysis and impact assessment realizable), but have to agree that it will take a significant event that compromises availability or integrity of some resource that the United States is completely dependent on to move this issue to the top of the priority list.  Unfortunately we all know implementing a security program and appropriate controls is not an overnight process.

Carlyle Group. (2008). 2008 Annual Report. Retrieved March 5, 2010, from Carlyle Group: http://www.carlyle.com/Annual%20Report/Carlyle_Annual_Report_2008.pdf

Singel, R. (2010, March 4). White House Cyber Czar: ‘There Is No Cyberwar’. Retrieved March 5, 2010, from Threat Level (Wired.com): http://www.wired.com/threatlevel/2010/03/schmidt-cyberwar/#more-14084

U.S. Government Acccountability Office. (2009, September 24). Critical Infrastructure Protection: Current Cyber Sector-Specific Planning Approach Needs Reassessment. Retrieved March 6, 2010, from U.S. Government Acccountability Office: http://www.gao.gov/products/GAO-09-969

Primer: Risk Management Lifecycle

Introduction

Risk is a factor that has the potential to have a negative influence on an organization.  There are several ways to view risk when relating it to concerns that should be considered and addressed for an organization.

A structured approach to addressing the concerns of risk for an organization is to implement a risk management program.  This program is an ongoing effort that is analyzed, adjusted and audited to ensure the risk profile is reduced to an acceptable level for the organizations risk tolerance.

This ongoing effort is referred to the Risk Management Lifecycle and understanding it is critical to implementing a successful form of it.

Overview

The risk management lifecycle at an abstract level is parsed into the following phases: identify assets, assess risk to assets, develop appropriate ways to manage risk and audit implemented controls.  Several methodologies have been developed to assist practitioners in executing a risk management program for an organization.  These methodologies include the NSA Information Assurance Methodology (NSA IAM), the McCumber Cube and Operationally Critical Threat Asset Vulnerabilities Evaluation (OCTAVE).

The NSA IAM provides a structured approach to defining an organization’s critical information assets, the organizations security needs for those assets and the organizations current security posture to secure the assets.  This approach involves parties from the information security team and management of the organization.  If followed correctly, this methodology produces an accurate assessment of an organization’s security needs and a road-map on addressing gaps.  This methodology was developed by the National Security Agency to meet the demand for information security assessments.  The NSA IAM is a repeatable process and is endorsed and recognized by the information security industry.

The McCumber Cube methodology offers a structured approach to assessing and managing security risk in IT systems.  The methodology relies on the implementer to identify information assets and then think of risk management in a deconstructed view across the all-too-familiar confidentiality, integrity and availability critical information characteristics.

OCTAVE is an asset-centric methodology for information risk assessment leveraging a workshop approach.  It is executed through 3 phases: an organizational, a technological, and a strategy and plan development.  This methodology is extremely document heavy and easy to follow for any professional despite background.  It has different versions to fit different sized organizations, and has a high transparency for the employee community.

The most significant drawback, and likely the reason it is not implemented by default, is the amount of time required for the program.  Time equals money in business, and often management and key players are interested in the financials then the quality and thoroughness of a risk assessment methodology.

Regardless of methodology selected, the phases are generally the same.  Each phase is discussed in greater detail, revealing the risk management lifecycle.

Identify

The first phase of the risk management lifecycle is the identification phase.  The organization must compile a list of all assets under control.  This list includes both non-tangible assets, such as informational assets, and tangible assets, such as hardware and human resources.

In addition to defining the assets under control for an organization, the identify phase identifies the risks present to each asset.  These risks can be environmental, natural or man-made.  Leveraging members from various departments provides useful insight and subject matter expertise on what risks are present.  The defined assets and risks provide input into phase two of the risk management lifecycle.

During the identification phase it is critical for a cross section of stakeholders to be represented.  Members from human resources, research, finance & accounting, marketing, IT and IS should all be present.  Including members from various departments will provide comprehensive coverage on asset and risk identification, and the process will provide exposure and awareness to various departments, enforcing the principal: risk is an integral part of the business.

A detailed list of critical assets and associated risks should be documented and maintained.  A list of this nature provides multiple benefits.  It gives the employee base, including management, an understanding of the assets under control for the organization and associated risk, some of which management may have been unaware of its existence or importance to the success of the organization.  This list can act as an input into several key processes including business continuity and disaster recovery plans to make recovery faster and more efficient.  Additionally, this list provides a starting point for the risk management lifecycle when it begins again.  Time and money does not need to be spent exhaustively listing assets and considering possible risks, instead the list can be used as a baseline and modifications can be accordingly.

Analyze Risk

The second phase of the risk management lifecycle is the analyze phase.  This phase reviews each risk and determines the impact an occurrence would have on the organization and its assets.  Impact is determined by evaluating what how negative effect would it have on the organization if the risk were to occur.  The impact for each risk can be evaluated using a scale of Low, Medium, and High.

[NOTE: The scale used to measure impact is relative to itself.  Industry commonly uses the 2 scales [Low, Medium, and High] and [1, 2, 3, 4, 5] as measurements.  It is the practitioner’s decision to determine the scale.  Regardless of the scale, it is important that the scale be used consistently and that each value has a clear, objective definition. ]

Once the risks are defined, relative to their impact, the probability of their occurrence must be determined.  Historical data, subject matter experts and industry predictions can be leveraged to determine the likelihood of an occurrence.  This probability and impact make up a matrix which yields the risk profile for each risk defined.  An example of a risk probability/impact matrix is shown.

An organization is now equipped to address these risks in an orderly and clear method.  For example a risk with a low impact and low probability can be ignored or pushed to the bottom of a priority list, where a high impact and high probability risk should be addressed as soon as possible.

Probability and Impact are the key elements to determing risk score

IMAGE FROM — http://www.mindtools.com/pages/article/newPPM_78.htm

Addressing Risk

The third phase of the risk management lifecycle is addressing the risks defined in phase two.  There are four approaches with which an organization can address each risk.  These approaches are:

1. Avoidance –This is the method of eliminating the risk altogether.  Physically moving an air conditioner that’s hanging above a server avoids the risk of it leaking liquids onto the server hardware.
2. Reduction – This is the commonly thought of form of addressing risk.  Risk reduction is the mitigation of the risk.  The risk cannot be avoided, but controls can be put in place to reduce the impact and/or probability of occurrence.  This effectively changes the risk profile for the risk and moves it to an acceptable level.
3. Transfer – Some risk cannot be mitigated, but it is inherently present due to the organizations business model.  Risk can be outsourced or insured to make the risk level acceptable.  Drivers have insurance on their vehicles because they cannot avoid the act of driving nor can they mitigate the risk of being hit by a bad driver.
4. Retention – Some risks are at acceptable levels for an organization without requiring intervention.  A low impact and low probability risk is an acceptable risk for many organizations.

An organization has many variables to consider when addressing identified risk including determining what options are available to address each risk, what the cost-benefit is for each option, the current budget constraints and the cost for the occurrence of the risk.  A budget might dictate that the optimal solution is too expensive, and a more affordable, less risk-mitigating solution needs to be implemented.  This may reduce the risk to a level that is not acceptable, but reduces it enough to not be an urgent issue.

Organizations need to look at addressing risks from a technology perspective, through policies and procedures, and by valuing the human factors.  Policies and procedures should be defined to meet the objectives of the organization and to address risk.  The policies and procedures will dictate how technology will be implemented to mitigate risk and educate the user population in secure practices.  Without appropriate, comprehensive policies, the implementation of controls and the actions of the user community are unlikely to be optimal for risk management.

The decisions on how risks will be addressed provide a risk mitigation implementation roadmap.  This roadmap can be projected to provide management with a clear understanding of what the organizations risk profile is today and what it is likely going to be in the future.  The future state can be projected but not predicted.  This is a key reason why risk management is a program and not a project.  This lifecycle must be repeated to assess, address, and handle the constantly changing risk environment.

Monitor/Audit

The final phase of risk management is the compliance and monitor phase.  Once controls have been put in place and policies developed, audits should be conducted to ensure they are being executed as expected.  A control is worthless to mitigating risk if it is not in place or being followed.

The risk must continue to be monitored.  Mitigating steps have been put in place, but the risk may occur and/or escalate in probability or impact.  For example, a server must not overheat, so an air conditioner is placed in the server room.  This addresses the risk of overheating, but the temperature must be monitored and an alert must be generated if the temperature reaches a threshold.  The air conditioner could fail (a newly created risk) or additional servers could be added and overwhelm the air conditioner.

Documentation of control compliance should be captured to provide feedback of how the control performs relative to its function of mitigating risk.  Controls that are deprecated or are no longer effective will result in risk reaching levels that must be addressed by an organization.  These findings provide an input into the first phase of the risk management lifecycle.

Conclusion

A strong risk management program cannot be implemented quickly, but must be implemented and mature through iterations of the lifecycle.  The environment, assets and risks are changing with laws, business objectives and technology advances.  This makes the risk profile a dynamic entity which must be constantly reevaluated to ensure an organization understands its risks and is addressing them to their risk tolerance levels.

Bibliography

Barcia, N. (2005, October 7). The 3 M’s of Risk Management – Monitor, Measure, Manage. Retrieved November 17, 2009, from Toomre Capital Markets LLC: http://www.toomre.com/node/126

CERT. (2008, September 17). OCTAVE Information Security Risk Evaluation. Retrieved November 14, 2009, from CERT.ORG: http://www.cert.org/octave/

McCumber, J. (2005). Assessing and managing security Risk in IT Systems; a structured methodology. Florida: Auerbach Publications.

MindTools. (n.d.). Risk Impact/Probability Chart. Retrieved November 17, 2009, from Mindtools: http://www.mindtools.com/pages/article/newPPM_78.htm

National Institute of Standards and Technology. (2002, July). Risk Management Guide for Information Technology Systems. Retrieved November 14, 2009, from NIST.Gov: http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

Third Party Vendor Risk Management

You can outsource the responsibility of risk, but not the accountability

Introduction

Today’s business demands fast services and readily available information.  Sharing information among businesses promotes higher quality services, better research and it allows businesses to focus on their primary business objectives without having the responsibility and necessity of certain departmental staffs (IT, Accounting, Support, etc).  When businesses utilize these third parties to assist in their business needs, they increase their risk profile.

The primary reason third party risk management demands serious consideration is when a company shares its information assets with another company, the potential for a compromise increases.  Specifically, it is the added risk associated with the information existing in another environment, under a different set of controls.   These controls are out of the primary company’s scope and their adequacy, enforceability and coverage are all unknown.

A business is still responsible for its information assets when it is in the custody of a third party service provider.  Businesses attempted to hide behind indemnity clauses, but it has been roundly accepted that indemnity agreements do not insulate an institution from responsibility to conduct banking, healthcare or any other business in a secure manner.

This gives rise to the art of third party risk management.  To successfully navigate the waters of this discipline, the key elements must be identified.  Like any information-centric security assessment, the risks must first be identified and then ways to mitigate, transfer, avoid or accept these risks must be developed.

Risk

Risk is a factor that has the potential to have a negative influence on an organization.  There are several ways to view risk when relating it to concerns that should be considered and addressed when working with a third party service provider.  Organizations cannot rely on an indemnity agreement to release them from the responsibility of their informational assets when they are in the custody of a non-controlled entity.

Risks that must be considered include:

1.      Operational Risk

The Office of the Comptroller of the Currency Administrator of National Banks defines operational risk as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. The definition includes legal risk, which is the risk of loss resulting from failure to comply with laws as well as prudent ethical standards and contractual obligations. It also includes the exposure to litigation from all aspects of an institution’s activities.

2.      Compliance Risk

Federal, state and SEC regulations dictate standards and minimum levels of security organizations must implement to protect their informational assets including personally identifiable information (PII), patient healthcare information (HPI), and company financials.

These regulations include Sarbanes-Oxley, HIPAA, PCI-DSS, Grahm-Leach-Bliley and Massachusetts Identity Theft Law.  These regulations issue financial penalties and delisting for organizations negligent to comply with them.

When an organization partners with a third party organization they are extending these requirements to their partner organizations.  An organization invites the risk to become non-compliant with these regulations, not by fault of their own internal controls and policies, but by the third parties negligence.

3.      Other Risk

Additional risks that must be given consideration when working with third party service providers include reputational, strategic, and credit risk.  These risk are difficult to quantify, but easy to understand.  If an organization is associated with bad business practices, even if it was not the organizations direct fault, it could pose irreversible damage.

An example of this risk materializing occurred on 7/13/2009.  Network Solutions, a third-party ecommerce merchant partner, reported a breach resulting in the disclosure of 573,928 credit cards information.  4,343 of networks solutions merchants had to report to their affected clients, they [the merchant], had disclosed the customer’s credit card information to an unauthorized party.  Network Solutions security issue directly resulted in reputational damage to 4,343 organizations.

TSP Relationship Quality Assessment

There are several methods that businesses can implement to evaluate a third party service providers control quality and maturity level for managing the security of informational assets.  These methods have been developed to address the unmanageable task of having each third party service provider’s client audit the information security controls.

Each approach holds benefits as well deficiencies.  These approaches, which are not an exclusive, include:

1.      WebTrust / SysTrust

WebTrust and SysTrust are offerings certified CPA’s employ to provide assurance testing for web applications and information systems, respectively.  These services are developed in part by the American Institute of Certified Public Accountants (AICPA), and leverage a common framework based on Trust Services Principles and Criteria, to address risk in IT.  Entities that employ an independent vendor to certify a system and/or attributes of a web application are afforded the opportunity to publicly assert the element that was certified is in compliance with WebTrust and/or SysTrust.

The WebTrust service meets different needs for e-commerce businesses.  These needs include consumer protection, online privacy and certification authorities.   When a web application or website has been successfully audited through the WebTrust service, a seal can be publically posted, asserting the system is in compliance.  There are 6 seals, each corresponding to its respective compliance status.  These seals include: Privacy, Security, Business Practice/ Transaction Integrity, Availability, Confidentiality, Non-repudiation.

A WebTrust certification audit can only be performed by a certified CPA.  A CPA does not directly align with a technical background or understanding, but a CPA must receive authority and certification in WebTrust assurance offerings prior to offering the service.  The AICPA has defined guidelines on additional knowledge a CPA should have to be prepared to properly offer this form of service.  According to the AICPA website:

The SysTrust professional service audits and certifies a system.  The four attributes of a system that are included in a full SysTrust audit are security, availability, maintainability and integrity.  All four components can be audited independently or altogether.  “SysTrust for system reliability” implies all four components are in-scope for the audit.

A system relative to a SysTrust evaluation consists of five key components organized to achieve a specified objective.  The five components are:

1. Infrastructure (facilities, equipment, and networks)
2. Software (systems, applications, utilities)
3. People (developers, operators, users, managers)
4. Procedures (automated and manual)
5. Data (transaction streams, files, databases, tables)   (AICPA and CICA, 2006)

A system that has been evaluated and its controls have been deemed as operating effectively is authorized to display a SysTrust seal.  The SysTrust offering is a traditional security assessment reviewing the critical elements: confidentiality, availability, integrity.

The service offerings are independent which lend credibility into the objectiveness of the audit, but only certified CPA’s are authorized to perform audits bringing into question the subject level expertise in appropriately testing technical elements.

2.      SAS70

SAS 70’s is the statement audit standard for service organizations.  There are two types, TYPE 1 and TYPE 2.  Type 1 includes a list of controls and Type 2 is operating effectiveness testing of the controls.

They are useful because they afford a business the knowledge of knowing whether a service provider is providing good internal controls and security.  They are typically used to show compliance when used as a tool for audits for such regulations as Sarbanes-Oxley, Grahm-Leach-Bliley and HIPAA.

SAS 70’s do have faults worth considering.  Only CPA’s are authorized to conduct SAS 70 audits.  This presents a question of confidence in the quality of the audit.  CPAs do not have technical backgrounds, so they are unprepared to look for what is missing.  Audit reports are typically favorable as if there is no control stated, than no control in place will match successfully.  This would be misleading to an individual relying on the report for quality of third party security controls.

3.      BITS

The BITS Shared Assessment methodology can be used independently or in parallel with other assessment methodologies.  It provides rigorous standards for security in industry and its evaluation technique is repeatable and objective.

BITS Shared Assessment works by using two tools, the Standardized information gathering questionnaire tool (SIG) and the Agreed Upon Procedures tool (AUP).   The SIG addresses control areas in ISO27002 and the AUP is objective and consistent in how its procedures are to be performed under each control area during an onsite assessment.

My Selection

I would select a BITS Share Assessment approach for evaluating my third party service providers in an ideal situation with a SAS70 Type II report to address controls not covered by BITS. (I state ideal as BITS is not a mandatory assessment methodology, and not all service providers would possess a completed a SIG and/or AUP).

The BITS Share Assessment has the credibility and developed confidence of the Big 4 accounting firms behind it.  This support and buy-in gives me assurance that the approach is sound and comprehensive.  The BITS is tailored for financial institutions, but it provides high-value controls aligned across multiple standards.

Conclusion

Third party risk management is critical for any organization that partners with third-parties, concerned with regulatory compliance, informational asset security and is serious about maturing into a strong, successful organization.  Without taking this risk into consideration, the total risk profile is not being taken into consideration, and an organization is gambling with its security posture.

There are several methodologies designed to assist service providers with handling the requests from organizations for documented evidence of security controls.  The costs and manageability would be prohibitive for service providers to not leverage some form of audited assessment.

These methodologies have faults and are not a guarantee that a service provider will avoid a compromise.  Service provider evaluation should include review of the documented evidence of security control policies and procedures, the quality of the controls and their enforcement.  In addition, an evaluation should take into consideration the methodology leveraged for the evaluation and determine the risk tolerance for the methodology.

Bibliography

AICPA and CICA. (2006). Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust and SysTrust). Retrieved 11 4, 2009, from WebTrust.org: http://www.webtrust.org/principles-and-criteria/item27818.pdf

AICPA. (2003). FAQs about WebTrust. Retrieved November 4, 2009, from American Institue of Certified Public Accountants: http://infotech.aicpa.org/Resources/Trust+Services/FAQs+About+WebTrust.htm

Chartered Accounts of Canada. (2008, June 30). Trust Services. Retrieved November 14, 2009, from WebTrust.Org: http://www.webtrust.org/

Comptroller of the Currency Administrator of National Banks. (2003, July 2). Supervisory Guidance on Operational Risk Advanced Measurement Approaches for Regulatory Capital. Retrieved November 14, 2009, from US Department of Treasury – Comptroller of the Currency Administrator of National Banks: http://www.occ.treas.gov/ftp/release/2003-53c.pdf

Jr, R. M. (2009). Managing Third Party Risk. Retrieved November 16, 2009, from System Experts: http://www.systemexperts.com/assets/tutors/SystemExperts-ThirdPartyRisk.pdf

Mills, E. (2009, July 27). Network Solutions breach exposes nearly 600,000. Retrieved November 18, 2009, from CNET: http://news.cnet.com/8301-27080_3-10296817-245.html

Santa Fe Group. (2009). Shared Assessments Web Site. Retrieved November 14, 2009, from Shared Assessments: http://www.sharedassessments.org/

US Senate Committee on Banking, Housing, and Urban Affairs. (1999, November 1). Information Regarding the Gramm-Leach-Bliley Act of 1999. Retrieved November 14, 2009, from Grahm-Leach-Bliley Act of 1999: http://banking.senate.gov/conf/

Time Warner Cable Exposes 65,000 Customer Routers to Remote Hacks

Dave Chen at Chenosaurus recently released an article regarding a vulnerability in a piece of widely deployed Time Warner router/modem device (SMC8014).  The gist of the vulnerability is the inclusion of cleartext admin credentials and admin level functions within the web-based interface.  Disabling Javascript on the browser causes the obfuscated admin content to be displayed.

Time Warner is in the midst of designing/testing/deploying a firmware update for this vulnerability.  This vulnerability enforces the notion that questions should be asked and one should not just take security at face value.

The entire Dave Chen article can be read here.

Review: McCumber Cube Methodology

The McCumber Cube methodology[1] offers a structured approach to assessing and managing security risk in IT systems.  The methodology relies on the implementer to identify information assets and then think of risk management in a deconstructed view across the all-to-familiar confidentiality, integrity and availability critical information characteristics.

This methodology is worth reviewing if you are a member of the information security community.  The benefits I have identified include:

• Information-Centric Approach – Typically methodologies utilize a technology-centric approach.  This approach is seen in industry in Common Criteria[2] and the (deprecated) Orange Book[3].  These methods of evaluating an information system for risk are excellent, but are unable to adapt gracefully as technology changes and matures, often resulting in large overhead costs to appropriately reevaluate the environment.The information-centric approach concerns itself with the informational assets and views the technology elements, along with policies and procedures and human factors (read training and awareness) as security measures to adequately secure the assets.  The creator of the methodology, John McCumber, produces strong points of the technology independence of the approach by showing that it can be appropriately applied to Napolean and his field generals, an information system environment completely void of modern technology.
• Reduced Resource Commitment – The methodology is not a process that needs to be replicated on a recurring basis; it is a methodology to use in the assessment and design phases of the security program.  Invoking the use of the methodology is called for when the information systems environment is significantly changed.Given the information-centric approach, an example (that is not a technology change) includes the recent passage of the Mass 201 CMR 17.00 law[4].  This law requires Massachusetts businesses to appropriately protect personal identifying information from unauthorized disclosure (data breach).  This law changes the value of these information assets for businesses, requiring a reassessment to occur, to insure an appropriate amount of security measures are leveraged to mitigate risk.
• Comprehensive Coverage – The gist of this methodology is to review the information system and identify the information assets.  For the assets in the system identify where they are relative to the following states: transmission, processing and storage.  For each of these states, give consideration to the confidentiality, integrity and availability (CIA) needs for the business.  This matrix will output a qualified risk value for the assets.  The implementer then utilizes technology, human factors and policies and procedures to mitigate the risk.The information will always be in one of the 3 states, and the CIA security characteristics are fundamental in our industry.  By giving each state/characteristic combination fair consideration, a comprehensive coverage of all the security needs are performed.  All too often availability is quickly assumed with a backup strategy, but by giving the topic a fair turn at the table, unexpected delays and outages due to a simple malfunction can be avoided.

I am not suggesting this methodology is the end-all, be-all for our industry, but the text that successfully informs on how it works and how to use it is a quick read that can be done in a weekend.  Regardless if you decide it is not the right approach for your clients or needs, it does provide thought provoking concepts, rooted in the information-centric approach to information systems.

[1] The McCumber Cube Methodology http://johnmccumber.org/_wsn/page2.html

[2]Common Criteria http://www.commoncriteriaportal.org/thecc.html

[3] Orange Book http://csrc.ncsl.nist.gov/publications/secpubs/rainbow/std001.txt

[4] Mass 201 CMR 17.00 http://www.mass.gov/Eoca/docs/idtheft/201CMR17amended.pdf

SecurityTubeCon being held in Cyberspace 11/6-11/8

Hacker / Information security conferences are a great venue to learn about cutting edge research and development going on in the industry.  BlackHat and DefCon are annual events drawing many great speakers and topics, but unfortunately (or fortunately in some peoples cases) they are both held in Las Vegas.  SchmooCon was designed to overcome this obstacle by being hosted in Washington DC, dubbed the east coast information security conference.

Catch SecurityTubeCon only online

For some people these conferences are too far away and/or too costly to attend.  SecurityTubeCon [1] is hoping to address this issue for the masses, by hosting the first information security conference to be hosted entirely in cyberspace.  The event will be 11/6 – 11/8, and is currently in an RFP phase for speakers.

SecurityTubeCon will publish an itinerary prior to the event and stream the talks live on the days of the event.  IRC will be used to ask questions to the speakers during their talks.  The cost is $0 for attending the event.  The conference’s goal is to democratize hacker conventions and make the experience available to all that are interested regardless of opportunity or situation.

[1] http://securitytubecon.org/index.html

Forensics and Incident Handling; Tomorrow’s In-Demand

The Foote Partners Research Group recently released their 2009 Trend Analysis for the Information Security industry (via BankInfoSecurity.com) [1].  Forensics and Incident Handling are the strong front runners, leading the way in most demanded skills category, most demanded competency category and most demanded certification.

With all the regulations and legislation being passed to hold companies accountable for protecting their data, one would think the focus would be on preventative measures more than detective measures.  I believe it can be explained by businesses maturing their information security processes and reducing the gaps in their Risk/Security personnel skill sets.

The following skills, competencies and certifications were identified by Foote as the most in-demand.  Note that Global Information Assurance Certification organization [2] lays claim to 50% of all in demand certifications.

The Most Demanded Skills
The security skills and aptitudes that attract the most interest from employers, according to Foote, are the more “hands-on” and technical ones, such as:

• Forensic Analysis
• Incident Handling & Analysis
• Security Architecture
• Ethical Hacking
• Network Security
• Security Management

The Most Demanded Competencies
Hand-in-hand with the most demanded skills come the top competencies needed on the job. These include:

• Forensics
• Identity and Access Management
• Intrusion Detection and Prevention
• Penetration Testing
• Threat/ vulnerability Assessment Management
• Litigation Support (e-discovery)
• Disk and File Level Encryption Solutions
• Data Leak Prevention
• Application Security
• Governance, Compliance & Audit

10 Most Valued Certifications
The following certifications appear in Foote Partner’s Hot List of certifications that are most in demand now, and will likely continue to be through the end of the year:

1. GIAC Certified Incident Handler
2. EC-Council/Certified Hacking Forensics Investigator
3. GIAC Certified Incident Manager
4. Check Point certified Master Architect
5. GIAC Certified Forensics Analyst
6. GIAC Certified Intrusion Analyst
7. Certified Information Systems Auditor
8. GIAC Secure Software Programmer
9. Systems Security Certified Practitioner
10. Cisco Certified Security Professional

[1]http://www.bankinfosecurity.com/articles.php?art_id=1782&rf=091909eb

[2]http://www.giac.org/