Public Security Program
Please refer to the main Plenary report for links to the presentations listed under the headings below.
Plenary: Securing Big Data
- KEYNOTE: Big Data and the Cloud: We Better get Security Right
Mary Ann Mezzapelle, Security Strategist, HP Enterprise Services
- KEYNOTE: Securing Big Data – Recommendations for Hadoop & NoSQL Environments
Adrian Lane, Analyst and CTO, Securosis
- Spotlight: Security Forum
Track: Security and Risk Management
- Why Risk It?
Jack Jones, CTO, CXOWARE, US
- Certification for Risk Analysts
Jim Hietala, Vice President, Security, The Open Group
Track: Secure Architectures
- A Systems Approach for Reliability Enhancement
Dr. Leila Meshkat, Senior Engineer, Jet Propulsion Laboratory, US
- SSL is not a Secure Architecture
Greg Sternberg, Jeppesen, USA
Member Meetings (Wednesday & Thursday)
Security Automation Workshop
Our Security Automation project is aimed at integrating several currently separate threads addressing aspects of system configuration, compliance monitoring, and automated response to incident alerts, into a holistic open standards-based security automation strategy. This workshop follows up on outcomes from our Q412 Open Group Meeting, to progress integration of NIST SCAP, the IETF SACM and MILE WGs, and the TCG Machine Health work, to integrate with our O-ACEML Standard for system configuration/compliance monitoring, DASv2 for Event Management, and AVOS for Virtualization Management.
The next IETF meeting is March 10-15, 2013 in Orlando Florida. It is important to attend IETF meetings if you wish to ensure that your viewpoints and contributions are addressed; absence and remote participation is assumed as “not sufficiently interested”. Also contribution of existing specifications is welcome but only if there is no IPR or copyright attached, since they expect to re-purpose any contributed documents to suit their own objectives – the original document owner loses all control.
The Security Forum project leader presented his view of the “big picture” framework that will create a security automation architecture into which the Security Forum can integrate required component solutions. The IETF only works on protocols, not architectures, so their SACM WG will not work on architecting the envisioned security automation solution. We therefore need to find ways to bring in the key players who we know are interested in working on developing this architecture. An interim proposal to consider is for the Security Forum to develop a White Paper, or even a Snapshot, to declare its interest in hosting this work.
The big-picture framework covers:
- Current attack situation
- Automating the Detect-Response Process components
- Typical Device State Pattern
- Monitoring examples for this pattern
- Aberration vectors
- Concept of Security Operations Center – a self-healing process
- Remediation – this requires a mindset shift that will allow a machine you don't control/own to remediate the state of your machine
This big-picture framework involves a four-stage cycle, a key component being TCG's IF-MAP, and the key four stages have existing potential standards to support them:
- Configure
- NIST-Mitre: SCAP
- NIST: CAESAR-FE (architecture)
- IETF: NEA, SACM
- The Open Group: O-ACEML
- Detect:
- Alert:
- IETF: IODEF, RID, MILE (was INCH)
- The Open Group: XDAS
- Remediate:
Risk Analyst Certification Workshop
This session built on the earlier public Risk Analyst track presentations by Jack Jones and Him Hietala (see above).
Work is in hand to prepare the required documents to support launch of this program, which is aimed for around the beginning of 2Q13. Required documents for all certification programs are:
- Conformance Requirements for the FAIR Certification Program
- Certification Policy
- Accreditation Policy for Trainers
A particular Security Forum members' interest in preparing this launch is to clearly differentiate between the value represented by The Open Group Risk Analyst Certification and ISACA’s recently launched CRISC. The proposed name for the program is “FAIR Risk Analyst Certification”, since it is based on CXOWARE’s Factor Analysis of Information Risk (FAIR), on which our Open Group Risk Taxonomy Standard is based. The initial launch will be at the “foundation” level. Work that will involve development and review in the Security Forum concerns completing the learning material to fill perceived gaps in the “Body of Knowledge” (BoK) – FAIR self-study materials – on which award of this Risk Analyst certification is to be based. The BOK study material will comprise:
- Introduction to Factor Analysis of Information Risk
- Risk Measurement using FAIR
- The Risk Analysis Process using FAIR
- Using FAIR – Case Studies and Examples
- Basic Control Considerations in FAIR Analyses
- Adopting FAIR within an Organization (this is valuable but not essential to the BoK)
plus an update to the Risk Taxonomy standard to align with the latest FAIR taxonomy. These study materials must be Open Group "Guides" (authoritative), not White Papers (informative).
Integrating Security into the TOGAF® Standard
The project leader led this TOGAF next Security Project (TNSP) joint meeting session with the Architecture Forum's TOGAF next (AF-TN) team.
The TNSP goal is to fully integrate security and risk management into the TOGAF Architecture Development Method (ADM), ensuring we highlight key security architecture issues as critical inputs during the ADM process, including where and when to engage Security Architect expertise. The re-structured TOGAF next Standard comprises three parts: Fundamentals (Part 1), Security Architect Practitioner Guidance (Part 2), and Recommended Practitioner Tools & Techniques (Part 3).
The TNSP leader explained and led review discussion on the TNSP members’ primary goals for this joint meeting:
- To verify that we have correct understandings on how our TNSP Part 1 Content, which we have passed to the AF-TN team, will be used to integrate core security architecture issues into TOGAF next.
Geoff presented a build-up slide explaining how TNSP members understand our TNSP Part 1 Content will be integrated into the main body of the AF-TN Parts 1 & 2, including working alongside nominated AF-TN members so we jointly agree how to present/write the integration material; it was agreed we will work with AF-TN Part 1 and Part 2 leaders to facilitate this engagement. He also explained how TNSP members then expect to “own” the responsibility for developing our Security Architecture practitioner guidance for Part 2, but to include ASF-TN members in joint review of our drafts, and to maintain continued close liaison with AF-TN members to validate that we remain well-aligned. The TNSP members also intend to identify Security Architect curriculum/learning objectives as a collation of criteria that may subsequently be used in developing a Security Architect professional certification program.
- To check that the TNSP draft Risk Management write-up we recommend for inclusion in the AF-TN team's draft for Part 1 is acceptable, and identify any significant issues requiring revision. The first section of the TNSP risk management draft is intended for integration into Part 1, and the later section on risk management for the ADM is intended to be integrated into AF-TN Part 2.
Members spent valuable time checking understandings on a number of issues. A significant discussion point was on viewing risk as an opportunity as well as a threat of loss, and TNSP members were warned that Enterprise Architects view risk as threat of loss, so we need to reconsider how we represent the TNSP’s intended meaning. We also noted several items which we agreed require us to revise our Risk Management draft before passing it over to AF-TN Part 1 leader for integration into the AF-TN Part 1 draft, and subsequent further review.
- To review the TNSP proposed Part 2 Outline plan for developing Security Architecture practitioner guides.
Useful feedback was noted, including on revisions to our definition for Security Architecture from the perspective of the Enterprise Architect, on including recommendations for how to set up a Security Architecture team to do Enterprise Security Architecture (to go into a TOGAF next project leaders guide?), and a number of mark-up changes to improve understanding of intended objectives.
A revised draft will be used by the TNSP members to proceed from this meeting to assign Contributor, Advisor, and Reviewer roles – as we did for TNSP Part 1 – for development of our proposed Security Architect Practitioner Guides, and to establish our roadmap for delivery of draft guides based on TNSP member resources. We also recognize that in developing Part 2 guidance, we will also identify relevant tools and techniques that we will wish to deploy in architecting security, and we should therefore note these as security components for TOGAF next Part 3 (Tools and Techniques).
Identity Management
The current activity in the Jericho Forum is to continue to promote awareness and adoption of the Identity Commandments which were published in May 2011 and which have demonstrated their robustness on the requirements that an effective global identity ecosystem must satisfy. The current best platform for promoting this is the Identity Ecosystem Steering Group (IDESG) and its hosting (and funding) organization – the US National Strategy for Trusted Identities in Cyberspace (NSTIC) initiative. The Open Group Jericho Forum is a member of the IDESG, and Ian Dobson acts as their representative to raise awareness and promote adoption of the Identity Commandments, the related Identity Key Concepts videos, and Identity Key Concepts guide.
In the IDESG meeting on February 5-7 in Phoenix AZ, the Jericho Forum will be an active part of a “Facilitated Pilot Demonstration” of the Identity Commandments “Core Identity and Persona” concept for an Identity Ecosystem. This facilitated pilot demonstration is a partnership activity lead by MIT Media Labs and a sub-group in the NSTIC-funded pilot on "University Corporation for Advanced Internet Development (UCAID)" – known publicly as "Internet 2" (see detailed description here). The aim is to demonstrate our Jericho Forum “Core Identity” as a practical service that uses a "fair terms of use” legal framework (as defined in the MIT Media Labs "Towards a Trustworthy Core Identity Infrastructure" draft paper).
Future Security Project Opportunities
The US American Bar Association’s Cyberlaw Group is active in several security-related areas in which we may like to take an interest – both as informative to our security interests and as possible opportunities to engage with them on developing joint value-add deliverables:
- Cloud Computing Project: More information is required here on their focus area.
- Cloud Security Questions: A checklist of questions an attorney should ask the client's cloud provider to answer. We should then ask what an attorney will be qualified to do with this information. Maybe we can help here?
- Corporate Director toolkit: We see potential to plug this into a FAIR risk assessment, as a use-case study or white paper on Corporate Director understanding on IT Risk.
- BYOD: What polices should an employer have about employees bringing their own device? The ABA strong advice is that employers should have a policy in place. BYOD could also be a good case-study for FAIR. BYOD may be a good Jericho Forum thought-leadership topic to take up in this context. Darren Argyle (IBM) gave a public presentation on BYOD in our Barcelona (Q412) conference.
The NCOIC – Network Centric Operations Industry Consortium (www.ncoic.org/home), the global leadership consortium for cross-domain net-centric interoperability – has a set of interoperability principles which we should take an interest in adopting. NCOIC is currently interested in potential for collaboration on secure interoperability for the Critical Infrastructure. Aspects of this they are looking into include:
- Legislation
- Pulling together cohesive standards from the many that have been published by a variety of interest groups
(NCOIC is starting an initiative on identifying existing standards and guides on cybersecurity in March 2013, in a meeting in Washington DC. Our security Forum projects on AVOS and Security Automation could contribute to this work.)
- Low-cost liability insurance arising from having effective threat mitigation measures in place
In the context of future “security” project opportunities for The Open Group, we should be aware of where security work is currently underway:
- In the Security Forum – raising confidence levels in IT business operations by identifying information security business requirements and developing open standards and guides that respond to them
- In the Jericho Forum – thought-leadership in future security requirements
- In the Real Time & Embedded Systems (RTES) Forum – on MILS and SCADA
- In the The Open Group Trusted Technology Provider Forum (OTTF) – on supply chain assurance
Data Protection
The Jericho Forum Data Protection White Paper was published in October 2012. In that paper we proposed a set of eight Data Protection principles, a core concept being that data protection should be as close to the data as possible, the ultimate state being self-protecting data (i.e., the data carries its own protection). The paper also proposed a migration strategy to move from existing practice to a much improved state.
Since publication of that paper, further emerging thoughts from Jericho Forum members has provided contributions towards a version of this Data Protection paper. Digital Rights Management (DRM) vendors – Microsoft, Oracle, Adobe, MC, and others – have their proprietary solutions but these are not interoperable, so we need an open standard for DRM. The XACML standard could provide a good basis for such an open standard – it does much of what is needed for a DRM solution.
The current framework we have adopted for identity, entitlement, and access to resources covers:
- Access control functions
- The identification process
- The authentication process
- The authorization process (the Security Forum’s XDSF publication explains how to do authorization correctly, and this also aligns with ISO/IEC 10181-3)
- Access control integration
- Information access protection, and the eight data protection principles
In the proposed next version of the Data Protection paper, additions are expected to include:
- Business requirements
- How data protection can be automated through recognition of a person’s profile of role, rights, entitlements, and preferences, to achieve a target of up to 90% correctness
- More security requirements
- Coverage on context
- Solution components and technical components
Target for delivery is end-2013.
Secure Mobile Architectures
A Security Forum SMA team has developed an SMA Snapshot, which will be formally reviewed by Security Forum members during the period February 5-19, leading to approval to publish.
Snapshots are draft documents aimed at raising industry awareness on our current direction and thinking on a particular subject, in advance of intention to proceed to develop an Open Group Standard. This Snapshot builds on the SMA Technical Study published by The Open Group in February 2004. It extends the architecture concepts described in that SMA Technical Study to show how the interoperability requirements for SMA implementations can now be met. It presents a broad range of diverse use-cases – including a Critical Infrastructure use-case – from which it derives a set of common architectural requirements, and describes a reference implementation for building SMAs.
Further work is now underway to upgrade this SMA Snapshot within six to nine months to become an Open Group SMA Standard. This work will include:
- Requirements Traceability:
Add an appendix to cross-reference the Chapter 2 summary of requirements to the point where they are addressed in the Reference Architecture, Chapter 5.
- Interoperability:
Extend the Interoperability Chapter 4 to ensure that implementations of SMA will be interoperable. If desirable, explain limitations/constraints for different levels of interoperability, and point out where and how these interoperability constraints function in the Reference Architecture.
- Implementation Guidelines:
SMA implementations will vary by application. Securely managing a water or sewer valve versus a manufacturing machine controller will determine the type and extent of the SMA needed to support the required implementation. First, we will describe a basic SMA implementation. Then, we will consider how this implementation will vary according to its application in a wide variety of deployments.
- Scope:
In the introduction, define the scope of SMA more tightly to explain its intended coverage, and add further acknowledgement of wider related mobile security issues affecting SMA implementations and why they are considered to be out of scope in the context of this SMA specification.
