Thought Leader Interview: Dr. William Turner on the Software-Defined Future ...Iver Band
As the Vice President, Datacenter Architecture at Presidio,
William Turner, PhD has more than 20 years of hand-son,
full-project-cycle experience in strategizing, designing and
deploying large-scale Fortune 500 networks and security
solutions. His extensive background in banking, security,
and government has yielded several well regarded industry
standards and noted reference models.
Dr. Turner envisions and drives a future in which sophisticated software provisions and de-provisions IT infrastructure automatically in response to business needs. The specialized appliances enterprises traditionally rely upon will be replaced by industry-standard hardware playing necessary roles on demand.
EAPJ conducted this interview from the perspective of an infrastructure architect considering a software-defined future for the networking, hosting and storage underlying a
major upcoming application investment.
Modeling Enterprise Risk Management and Security with the ArchiMate LanguageIver Band
The document provides an overview of how the ArchiMate modeling language can be used to model enterprise risk management and security concepts and relationships. It summarizes relevant risk and security standards and frameworks and extracts a set of core concepts. It then demonstrates how these concepts can be modeled using the ArchiMate language by mapping the concepts to ArchiMate elements and including examples from case studies. The document concludes that the ArchiMate language allows for modeling of the majority of common risk and security concepts and their relationships to other enterprise architecture concepts.
Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 M...Iver Band
A thorough comparison of the ArchiMate 2.0 metamodel with the Content Metamodel
from the TOGAF 9.1 Architecture Content Framework reveals that these two Open
Group standards are highly compatible. The ArchiMate 2.0 visual modeling language
is therefore well suited for architecture initiatives guided by the TOGAF 9.1 standard,
and this White Paper provides both theoretical preparation and practical guidance for
users of the ArchiMate language working on such initiatives.
This work supports The Open Group vision of Boundaryless Information Flow by
further enabling the combined use of the TOGAF standard and the ArchiMate
modeling language for consistent representation of architectural information across
diverse organizations, systems, and initiatives.
This issue focuses on how EA can empower organizations to achieve their goals. EA and quality expert Mike Novak compares the TOGAF®1 framework for enterprise architecture with the Baldrige approach to organizational performance assessment and improvement, and shows how organizations could benefit from integrating the two paradigms. This is a great article for all those who have wondered about the relationship between EA and quality practices, or would like to learn more about either paradigm. The article assumes a bit of familiarity with the TOGAF standard, so novices should consult one of the references at the bottom of this page. This issue also features an interview with Mike Callahan, a senior partner in AgileLayer, a business architecture methodology, software and consulting provider. Mike Callahan introduces us to his area of expertise, and explains how business architects practice many of the methods Mike Novak describes in his TOGAF/Baldrige article.
Enhancing the ArchiMate® Standard with a Responsibility Modeling Language for...Iver Band
In this paper, we describe an innovative approach for aligning the
business layer and the application layer of ArchiMate to ensure
that applications manage access rights consistently with enterprise
goals and risk tolerances. The alignment is realized by using the
responsibility of the employees, which we model using ReMoLa.
The main focus of the alignment targets the definition and the
assignment of the access rights needed by the employees
according to business specification. The approach is illustrated
and validated with a case study in a municipal hospital in
Luxembourg.
In this presentation Bruno Vandenborre, The Open Group accredited trainer at Real IRM, explores the purpose and utility of the new version of the ArchiMate standard. As well as a look at the updates and changes to the new version, he discusses the various responses and critiques to ArchiMate, and provide insight into how ArchiMate benefits the South African market.
This document provides an agenda and overview for a joint workshop on security modeling hosted by the ArchiMate Forum and Security Forum. The workshop aims to identify opportunities to improve the conceptual and visual modeling of enterprise information security using TOGAF and ArchiMate. The agenda includes introductions, a research spotlight on strengthening role-based access control with responsibility modeling, an open discussion on complementing TOGAF and ArchiMate with enhanced security modeling, and identifying next steps. The workshop purpose is to enable better security architecture decisions and drive usage of TOGAF and ArchiMate for security architecture.
Thought Leader Interview: Dr. William Turner on the Software-Defined Future ...Iver Band
As the Vice President, Datacenter Architecture at Presidio,
William Turner, PhD has more than 20 years of hand-son,
full-project-cycle experience in strategizing, designing and
deploying large-scale Fortune 500 networks and security
solutions. His extensive background in banking, security,
and government has yielded several well regarded industry
standards and noted reference models.
Dr. Turner envisions and drives a future in which sophisticated software provisions and de-provisions IT infrastructure automatically in response to business needs. The specialized appliances enterprises traditionally rely upon will be replaced by industry-standard hardware playing necessary roles on demand.
EAPJ conducted this interview from the perspective of an infrastructure architect considering a software-defined future for the networking, hosting and storage underlying a
major upcoming application investment.
Modeling Enterprise Risk Management and Security with the ArchiMate LanguageIver Band
The document provides an overview of how the ArchiMate modeling language can be used to model enterprise risk management and security concepts and relationships. It summarizes relevant risk and security standards and frameworks and extracts a set of core concepts. It then demonstrates how these concepts can be modeled using the ArchiMate language by mapping the concepts to ArchiMate elements and including examples from case studies. The document concludes that the ArchiMate language allows for modeling of the majority of common risk and security concepts and their relationships to other enterprise architecture concepts.
Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 M...Iver Band
A thorough comparison of the ArchiMate 2.0 metamodel with the Content Metamodel
from the TOGAF 9.1 Architecture Content Framework reveals that these two Open
Group standards are highly compatible. The ArchiMate 2.0 visual modeling language
is therefore well suited for architecture initiatives guided by the TOGAF 9.1 standard,
and this White Paper provides both theoretical preparation and practical guidance for
users of the ArchiMate language working on such initiatives.
This work supports The Open Group vision of Boundaryless Information Flow by
further enabling the combined use of the TOGAF standard and the ArchiMate
modeling language for consistent representation of architectural information across
diverse organizations, systems, and initiatives.
This issue focuses on how EA can empower organizations to achieve their goals. EA and quality expert Mike Novak compares the TOGAF®1 framework for enterprise architecture with the Baldrige approach to organizational performance assessment and improvement, and shows how organizations could benefit from integrating the two paradigms. This is a great article for all those who have wondered about the relationship between EA and quality practices, or would like to learn more about either paradigm. The article assumes a bit of familiarity with the TOGAF standard, so novices should consult one of the references at the bottom of this page. This issue also features an interview with Mike Callahan, a senior partner in AgileLayer, a business architecture methodology, software and consulting provider. Mike Callahan introduces us to his area of expertise, and explains how business architects practice many of the methods Mike Novak describes in his TOGAF/Baldrige article.
Enhancing the ArchiMate® Standard with a Responsibility Modeling Language for...Iver Band
In this paper, we describe an innovative approach for aligning the
business layer and the application layer of ArchiMate to ensure
that applications manage access rights consistently with enterprise
goals and risk tolerances. The alignment is realized by using the
responsibility of the employees, which we model using ReMoLa.
The main focus of the alignment targets the definition and the
assignment of the access rights needed by the employees
according to business specification. The approach is illustrated
and validated with a case study in a municipal hospital in
Luxembourg.
In this presentation Bruno Vandenborre, The Open Group accredited trainer at Real IRM, explores the purpose and utility of the new version of the ArchiMate standard. As well as a look at the updates and changes to the new version, he discusses the various responses and critiques to ArchiMate, and provide insight into how ArchiMate benefits the South African market.
This document provides an agenda and overview for a joint workshop on security modeling hosted by the ArchiMate Forum and Security Forum. The workshop aims to identify opportunities to improve the conceptual and visual modeling of enterprise information security using TOGAF and ArchiMate. The agenda includes introductions, a research spotlight on strengthening role-based access control with responsibility modeling, an open discussion on complementing TOGAF and ArchiMate with enhanced security modeling, and identifying next steps. The workshop purpose is to enable better security architecture decisions and drive usage of TOGAF and ArchiMate for security architecture.
The ArchiSurance Case Study is a fictitious example developed to illustrate the use of
the ArchiMate® modeling language in the context of the TOGAF® framework. The
Case Study concerns the insurance company ArchiSurance, which has been formed as
the result of a merger of three previously independent companies. The Case Study
describes the baseline architecture of the company and then a number of change
scenarios.
This Case Study is required to be used as an example throughout accredited
ArchiMate training courses. However, it is not part of the definition of TOGAF. This
work supports The Open Group vision of Boundaryless Information Flow by
illustrating the combined use of the TOGAF and ArchiMate standards for consistent
representation of architectural information across diverse organizations, systems, and
initiatives.
ArchiMate 3.0: A New Standard for ArchitectureIver Band
This keynote presentation from the July 2016 Open Group Austin Conference introduces the new version of the ArchiMate standard. ArchiMate 3.0 extends the language with various concepts that help enterprise architects tackle challenges in digital transformation and business change. This major new version introduces explicit support for capability-based planning, and improves linkage between business strategy and all architecture layers. ArchiMate 3.0 also enables modelers to describe the Internet of Things and the systems of the physical world, such as manufacturing and logistics. In addition, the new version supports more compact and intuitive visual models. This presentation includes examples that use these improvements and demonstrates how architects can benefit from them.
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...Iver Band
A half-day introduction to the ArchiMate language, including core concepts, a visual Overview, and a case study. Introduces the entire language, including the Business, Application and Technology layers as well as the Motivation and implementation and Migration extensions. Ideal for enterprise and solution architects and other architecture contributors.
The case study uses the free Archi tool, and includes download instructions. Those interested in learning the language can attempt each case study exercise using Archi, and flip to the next slide to check their work.
The TOGAF® Architecture Development Method recommends that "an architecture description be encoded in a standard language". As the Open Group standard for enterprise modeling, Archimate is a strong candidate for this role. This presentation will explore how a diversified financial services company selected and is using Archimate for its TOGAF® implementation. The speaker will compare available enterprise modeling languages and explain why Archimate was selected, and will explain how his organization developed an enabling metamodel and diagram templates using a leading enterprise modeling tool. Methodology transition will also be covered, including how existing diagram types were mapped to TOGAF®, and how TOGAF® diagram content was mapped to Archimate.
Delivered at February 2011 Open Group San Diego Conference
Modeling Big Data with the ArchiMate 3.0 LanguageIver Band
Health care enterprises use big data methods and technologies to gain insights for improving the efficacy, efficiency, and accessibility of their services. Effective big data initiatives require shared understanding among diverse stakeholders of business challenges and the often complex architectures required to address them. Enterprise and solution architects can use the ArchiMate language to build this understanding with compelling visual models.
This presentation introduces the ArchiMate 3.0 language, and uses it to explore the US National Institute of Standards and Technology (NIST) Big Data Reference Architecture (NBDRA), and to present a health care case study based on the NBDRA. Participants will learn how to use the ArchiMate 3.0 language, in alignment with the TOGAF framework, to propose, justify and plan big data initiatives, and to guide their successful implementation.
This white paper discusses how insurance companies can use the TOGAF and ArchiMate standards together with the ACORD framework and standards to manage their enterprise architectures and standardize their operations. It provides an overview of TOGAF, ArchiMate, and the ACORD initiatives. It then presents a case study of modeling the new business setup process for group term life insurance using these standards. The paper concludes that the ACORD framework and standards complement TOGAF and ArchiMate and can help insurance organizations achieve boundaryless information flow.
An Introduction to the ArchiMate 3.0 SpecificationIver Band
This White Paper provides an overview of the ArchiMate® 3.0 Specification, an Open Group Standard, including the role of the language in Enterprise Architecture, a description of its structure and content, and a summary of the new features of this major update.
The ArchiMate 3.0 Specification is a major update to the ArchiMate 2.1 Specification, and was published as an Open Group Standard in June 2016. New features included in Version 3.0 include elements for modeling the enterprise at a strategic level, such as capability, resource, and outcome. It also includes support to model the physical world of materials and equipment. Furthermore, the consistency and structure of the language have been improved, definitions have been aligned with other standards, and its usability has been enhanced in various other ways.
This Case Study demonstrates the value of the ArchiMate® 2.1 modeling language for planning and expressing complex business transformation. The Case Study is about a fictitious manufacturer named ArchiMetal. Through high-level architecture modeling, the ArchiMate language illuminates the coherence between an organization, and its processes, applications, and infrastructure. This Case Study presents examples of ArchiMate models that can be elaborated as necessary for analysis, communication, decision support, and implementation.
This month, there are two important events taking place – one in Mumbai (India) and other one in Abu Dhabi (UAE) and ICISS is Event Partner for both of them! While the seminar in Mumbai, “Secutech India Safety & Security Conclave 2014” is focusing on Security Solutions for Vertical Markets, the “Global Energy Security Conference 2014” in Abu Dhabi will have in-depth discussions on Corporate Security Integration with the Business, Security Mitigation Measures for International Companies and Ensuring Security at Oil & Gas Infrastructure in High Risk Areas against Terrorism.
The Pinkerton initiatives in India have been very useful in identifying the real threats faced by various sectors and strategies to mitigate them. The past survey results have been found very useful by the Corporates operating in India and for those wishing to set-up their operations in India in formulating their Security & Risk Policies and the measures to counter the treats. Like last year, the ICISS has partnered in this survey and we request all our readers to positively respond to this survey.
Capt S B Tyagi
For ICISS
This document presents security principles for cloud and service-oriented architecture (SOA) from The Open Group's Security for the Cloud & SOA Project. It provides general security principles that are widely applicable to securely designing enterprise architectures, as well as additional principles specifically relevant to securing cloud and SOA environments. The principles are intended to serve as a benchmark for assessing security concepts, designs, solutions, standards compliance, and system architectures.
The Open Government Platform (OpenGP) aims to:
1) Create an open source alternative to proprietary suites from Microsoft, Oracle, and IBM.
2) Share results from customers, suppliers, and projects selecting open methods and products.
3) Create customer value faster and with higher quality.
4) Establish challenging and meaningful IT workplaces.
1. Open Source Software has enabled collaboration and connection through shared circulation of software. It addresses technological challenges in online learning.
2. Open Source Software is widely used in education from primary to post-secondary levels. It can be used on older hardware, benefiting lower-income individuals. Savings on software allows investing in other education.
3. Open Source Software development involves public collaboration on projects. Others can modify code to suit individual/group needs. It is compatible with most hardware/applications and used in business and education communities worldwide.
Open Source Insight: Open Source 360 Survey, DockerCon 2017, & More on the Cl...Black Duck by Synopsys
In open source security and cybersecurity news: Take the opportunity to join the Open Source 360 Survey and help give the world a snapshot of the state of open source in usage, risk, contributions and governance/policies. The top four sessions you don’t want to miss at Dockercon 2017. Does the Cloudera IPO really argue against open source business? TechCrunch creates a new index to track the explosive growth of open source. Why creating an open source ecosystem doesn't mean you're taking on security risks. And building containerized ecosystems with Ansible Container.
Using the TOGAF® 9.1 Framework with the ArchiMate® 2.1 Modeling LanguageIver Band
This White Paper describes the TOGAF®
9.1 framework and the ArchiMate®
2.1 modeling language, showing at a high level how these two open standards from The Open Group can
be used together.
The main observations are:
The TOGAF framework and the ArchiMate language overlap in their use of viewpoints, and the concept of an underlying common repository of architectural artifacts and models; i.e., they have a firm common foundation.
The two standards complement each other with respect to the definition of an architecture development process and the definition of an Enterprise Architecture modeling language.
The ArchiMate 2.1 standard supports modeling of the architectures throughout the phases of the TOGAF Architecture Development Method (ADM).
The combined use of the TOGAF framework with the ArchiMate modeling language can support better communication with stakeholders inside and outside organizations supporting The Open Group vision of Boundaryless Information Flow™.
The document discusses the seven levers of digital transformation that can guide decision-makers. It introduces the seven levers as business process transformation, customer engagement and experience, product or service digitization, IT and delivery transformation, organizational culture, strategy, and ecosystem. It provides an overview of each lever and groups them into levers related to continuously delivering value to users, levers that support operational execution and strategy, and levers about vision, culture and partnerships. The seven levers framework is intended to help assess gaps, address them successfully, and guide investment decisions to realize the benefits of digital transformation.
Companies can engage in the 3Os in many ways and for different reasons. In many cases, strategic and competitive advantages are at the core of a company’s decisions, but in other cases, motivations can involve social and ethical considerations such as reciprocity, altruism, and democratization of knowledge. In this talk, we outline the main business-related motivations identified by the ZOOOM project for using and contributing to FOSS. Among them: pursuing competitive advantage, reduction of development costs, technological innovation, access to knowledge or assets, and interoperability. Based on the interviews conducted by the ZOOOM partners, we also discuss major challenges and risks that businesses leveraging the 3Os must navigate.
The document describes the Open Government Platform (OpenGP) which aims to:
1) Create an open source alternative to proprietary enterprise suites like Microsoft and Oracle.
2) Share results from customers, suppliers, and projects connected to suite selections.
3) Create customer value faster and with higher quality.
The OpenGP community is governed under a GPL v3 license and aims to build upon established open source communities and software rated highly by analysts. It provides a secure integrated platform for government solutions based on open methodologies and technologies.
Open source software is widely used but faces security challenges as vulnerabilities have been found in widely used open source components. While most companies do not currently monitor open source code for security issues, the open source community is adapting to improve security. New approaches for security processes and tools are emerging and will provide increased choices for addressing open source security over time.
The ArchiSurance Case Study is a fictitious example developed to illustrate the use of
the ArchiMate® modeling language in the context of the TOGAF® framework. The
Case Study concerns the insurance company ArchiSurance, which has been formed as
the result of a merger of three previously independent companies. The Case Study
describes the baseline architecture of the company and then a number of change
scenarios.
This Case Study is required to be used as an example throughout accredited
ArchiMate training courses. However, it is not part of the definition of TOGAF. This
work supports The Open Group vision of Boundaryless Information Flow by
illustrating the combined use of the TOGAF and ArchiMate standards for consistent
representation of architectural information across diverse organizations, systems, and
initiatives.
ArchiMate 3.0: A New Standard for ArchitectureIver Band
This keynote presentation from the July 2016 Open Group Austin Conference introduces the new version of the ArchiMate standard. ArchiMate 3.0 extends the language with various concepts that help enterprise architects tackle challenges in digital transformation and business change. This major new version introduces explicit support for capability-based planning, and improves linkage between business strategy and all architecture layers. ArchiMate 3.0 also enables modelers to describe the Internet of Things and the systems of the physical world, such as manufacturing and logistics. In addition, the new version supports more compact and intuitive visual models. This presentation includes examples that use these improvements and demonstrates how architects can benefit from them.
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...Iver Band
A half-day introduction to the ArchiMate language, including core concepts, a visual Overview, and a case study. Introduces the entire language, including the Business, Application and Technology layers as well as the Motivation and implementation and Migration extensions. Ideal for enterprise and solution architects and other architecture contributors.
The case study uses the free Archi tool, and includes download instructions. Those interested in learning the language can attempt each case study exercise using Archi, and flip to the next slide to check their work.
The TOGAF® Architecture Development Method recommends that "an architecture description be encoded in a standard language". As the Open Group standard for enterprise modeling, Archimate is a strong candidate for this role. This presentation will explore how a diversified financial services company selected and is using Archimate for its TOGAF® implementation. The speaker will compare available enterprise modeling languages and explain why Archimate was selected, and will explain how his organization developed an enabling metamodel and diagram templates using a leading enterprise modeling tool. Methodology transition will also be covered, including how existing diagram types were mapped to TOGAF®, and how TOGAF® diagram content was mapped to Archimate.
Delivered at February 2011 Open Group San Diego Conference
Modeling Big Data with the ArchiMate 3.0 LanguageIver Band
Health care enterprises use big data methods and technologies to gain insights for improving the efficacy, efficiency, and accessibility of their services. Effective big data initiatives require shared understanding among diverse stakeholders of business challenges and the often complex architectures required to address them. Enterprise and solution architects can use the ArchiMate language to build this understanding with compelling visual models.
This presentation introduces the ArchiMate 3.0 language, and uses it to explore the US National Institute of Standards and Technology (NIST) Big Data Reference Architecture (NBDRA), and to present a health care case study based on the NBDRA. Participants will learn how to use the ArchiMate 3.0 language, in alignment with the TOGAF framework, to propose, justify and plan big data initiatives, and to guide their successful implementation.
This white paper discusses how insurance companies can use the TOGAF and ArchiMate standards together with the ACORD framework and standards to manage their enterprise architectures and standardize their operations. It provides an overview of TOGAF, ArchiMate, and the ACORD initiatives. It then presents a case study of modeling the new business setup process for group term life insurance using these standards. The paper concludes that the ACORD framework and standards complement TOGAF and ArchiMate and can help insurance organizations achieve boundaryless information flow.
An Introduction to the ArchiMate 3.0 SpecificationIver Band
This White Paper provides an overview of the ArchiMate® 3.0 Specification, an Open Group Standard, including the role of the language in Enterprise Architecture, a description of its structure and content, and a summary of the new features of this major update.
The ArchiMate 3.0 Specification is a major update to the ArchiMate 2.1 Specification, and was published as an Open Group Standard in June 2016. New features included in Version 3.0 include elements for modeling the enterprise at a strategic level, such as capability, resource, and outcome. It also includes support to model the physical world of materials and equipment. Furthermore, the consistency and structure of the language have been improved, definitions have been aligned with other standards, and its usability has been enhanced in various other ways.
This Case Study demonstrates the value of the ArchiMate® 2.1 modeling language for planning and expressing complex business transformation. The Case Study is about a fictitious manufacturer named ArchiMetal. Through high-level architecture modeling, the ArchiMate language illuminates the coherence between an organization, and its processes, applications, and infrastructure. This Case Study presents examples of ArchiMate models that can be elaborated as necessary for analysis, communication, decision support, and implementation.
This month, there are two important events taking place – one in Mumbai (India) and other one in Abu Dhabi (UAE) and ICISS is Event Partner for both of them! While the seminar in Mumbai, “Secutech India Safety & Security Conclave 2014” is focusing on Security Solutions for Vertical Markets, the “Global Energy Security Conference 2014” in Abu Dhabi will have in-depth discussions on Corporate Security Integration with the Business, Security Mitigation Measures for International Companies and Ensuring Security at Oil & Gas Infrastructure in High Risk Areas against Terrorism.
The Pinkerton initiatives in India have been very useful in identifying the real threats faced by various sectors and strategies to mitigate them. The past survey results have been found very useful by the Corporates operating in India and for those wishing to set-up their operations in India in formulating their Security & Risk Policies and the measures to counter the treats. Like last year, the ICISS has partnered in this survey and we request all our readers to positively respond to this survey.
Capt S B Tyagi
For ICISS
This document presents security principles for cloud and service-oriented architecture (SOA) from The Open Group's Security for the Cloud & SOA Project. It provides general security principles that are widely applicable to securely designing enterprise architectures, as well as additional principles specifically relevant to securing cloud and SOA environments. The principles are intended to serve as a benchmark for assessing security concepts, designs, solutions, standards compliance, and system architectures.
The Open Government Platform (OpenGP) aims to:
1) Create an open source alternative to proprietary suites from Microsoft, Oracle, and IBM.
2) Share results from customers, suppliers, and projects selecting open methods and products.
3) Create customer value faster and with higher quality.
4) Establish challenging and meaningful IT workplaces.
1. Open Source Software has enabled collaboration and connection through shared circulation of software. It addresses technological challenges in online learning.
2. Open Source Software is widely used in education from primary to post-secondary levels. It can be used on older hardware, benefiting lower-income individuals. Savings on software allows investing in other education.
3. Open Source Software development involves public collaboration on projects. Others can modify code to suit individual/group needs. It is compatible with most hardware/applications and used in business and education communities worldwide.
Open Source Insight: Open Source 360 Survey, DockerCon 2017, & More on the Cl...Black Duck by Synopsys
In open source security and cybersecurity news: Take the opportunity to join the Open Source 360 Survey and help give the world a snapshot of the state of open source in usage, risk, contributions and governance/policies. The top four sessions you don’t want to miss at Dockercon 2017. Does the Cloudera IPO really argue against open source business? TechCrunch creates a new index to track the explosive growth of open source. Why creating an open source ecosystem doesn't mean you're taking on security risks. And building containerized ecosystems with Ansible Container.
Using the TOGAF® 9.1 Framework with the ArchiMate® 2.1 Modeling LanguageIver Band
This White Paper describes the TOGAF®
9.1 framework and the ArchiMate®
2.1 modeling language, showing at a high level how these two open standards from The Open Group can
be used together.
The main observations are:
The TOGAF framework and the ArchiMate language overlap in their use of viewpoints, and the concept of an underlying common repository of architectural artifacts and models; i.e., they have a firm common foundation.
The two standards complement each other with respect to the definition of an architecture development process and the definition of an Enterprise Architecture modeling language.
The ArchiMate 2.1 standard supports modeling of the architectures throughout the phases of the TOGAF Architecture Development Method (ADM).
The combined use of the TOGAF framework with the ArchiMate modeling language can support better communication with stakeholders inside and outside organizations supporting The Open Group vision of Boundaryless Information Flow™.
The document discusses the seven levers of digital transformation that can guide decision-makers. It introduces the seven levers as business process transformation, customer engagement and experience, product or service digitization, IT and delivery transformation, organizational culture, strategy, and ecosystem. It provides an overview of each lever and groups them into levers related to continuously delivering value to users, levers that support operational execution and strategy, and levers about vision, culture and partnerships. The seven levers framework is intended to help assess gaps, address them successfully, and guide investment decisions to realize the benefits of digital transformation.
Companies can engage in the 3Os in many ways and for different reasons. In many cases, strategic and competitive advantages are at the core of a company’s decisions, but in other cases, motivations can involve social and ethical considerations such as reciprocity, altruism, and democratization of knowledge. In this talk, we outline the main business-related motivations identified by the ZOOOM project for using and contributing to FOSS. Among them: pursuing competitive advantage, reduction of development costs, technological innovation, access to knowledge or assets, and interoperability. Based on the interviews conducted by the ZOOOM partners, we also discuss major challenges and risks that businesses leveraging the 3Os must navigate.
The document describes the Open Government Platform (OpenGP) which aims to:
1) Create an open source alternative to proprietary enterprise suites like Microsoft and Oracle.
2) Share results from customers, suppliers, and projects connected to suite selections.
3) Create customer value faster and with higher quality.
The OpenGP community is governed under a GPL v3 license and aims to build upon established open source communities and software rated highly by analysts. It provides a secure integrated platform for government solutions based on open methodologies and technologies.
Open source software is widely used but faces security challenges as vulnerabilities have been found in widely used open source components. While most companies do not currently monitor open source code for security issues, the open source community is adapting to improve security. New approaches for security processes and tools are emerging and will provide increased choices for addressing open source security over time.
The summary of the OpenChain Monthly Meeting document is:
1. The meeting covered announcements regarding increased support for the OpenChain Security Assurance Specification from certification organizations globally, as well as the first organization achieving conformance with the spec.
2. Updates were provided on SPDX Python tools and an upcoming OSPOlogy event.
3. The OpenChain Automation work group discussed publishing the Capability Map in different formats and a new open source compliance database project.
4. Discussions were held on potential improvements to the License Compliance and Security Assurance specifications.
5. The Education work group outlined priorities like a document on focus areas and continuing work on revamping the website.
All Things Open 2023
Presented at All Things Open 2023
Presented by Deb Bryant - Open Source Initiative, Patrick Masson - Apereo Foundation, Stephen Jacobs - Rochester Institute of Technology, Ruth Suehle - SAS, & Greg Wallace - FreeBSD Foundation
Title: Open Source and Public Policy
Abstract: New regulations in the software industry and adjacent areas such as AI, open science, open data, and open education are on the rise around the world. Cyber Security, societal impact of AI, data and privacy are paramount issues for legislators globally. At the same time, the COVID-19 pandemic drove collaborative development to unprecedented levels and took Open Source software, open research, open content and data from mainstream to main stage, creating tension between public benefit and citizen safety and security as legislators struggle to find a balance between open collaboration and protecting citizens.
Historically, the open source software community and foundations supporting its work have not engaged in policy discussions. Moving forward, thoughtful development of these important public policies whilst not harming our complex ecosystems requires an understanding of how our ecosystem operates. Ensuring stakeholders without historic benefit of representation in those discussions becomes paramount to that end.
Please join our open discussion with open policy stakeholders working constructively on current open policy topics. Our panelists will provide a view into how oss foundations and other open domain allies are now rising to this new challenge as well as seizing the opportunity to influence positive changes to the public’s benefit.
Topics: Public Policy, Open Science, Open Education, current legislation in the US and EU, US interest in OSS sustainability, intro to the Open Policy Alliance
Find more info about All Things Open:
On the web: https://www.allthingsopen.org/
Twitter: https://twitter.com/AllThingsOpen
LinkedIn: https://www.linkedin.com/company/all-things-open/
Instagram: https://www.instagram.com/allthingsopen/
Facebook: https://www.facebook.com/AllThingsOpen
Mastodon: https://mastodon.social/@allthingsopen
Threads: https://www.threads.net/@allthingsopen
2023 conference: https://2023.allthingsopen.org/
Tenable: Economic, Operational and Strategic Benefits of Security Framework A...Mighty Guides, Inc.
Lester Godsey discusses how a security framework provides a baseline for acceptable security practices in an organization and enables security conversations with other business areas. It gives context for discussing exceptions or additional controls. Most businesses customize frameworks based on their specific needs and regulations. Having a framework in place allows an organization to design security metrics that map to important controls and align with business objectives.
Lee Bailey notes that security frameworks help mature a security practice by guiding organizations from identifying needs to defining controls and processes. It enables aligning security and business objectives by making security decisions based on risk and explaining security issues to non-technical staff. For retailers, payment security standards help maintain customer trust and confidence, supporting the core business strategy. Frameworks also simplify
This document discusses open source software, its history and uses. Open source software has many benefits including being free, allowing for collaboration and modification of code. It can also be used on older hardware, saving schools and individuals money. Examples of popular open source software mentioned are the Linux operating system, Mozilla Firefox web browser, and Apache web server. The document concludes that open source software adoption will likely continue to expand due to its low costs and collaborative nature.
More information:https://flevy.com/browse/flevypro/culture-of-security-4020
Advancement in technology, unfortunately, has helped attackers be more aggressive and capable of inflicting more damage to IT systems and infrastructure deployed at most enterprises today.
Application security tools and techniques are also evolving continuously. However, they are not up to the mark, as organizations still fall prey to vulnerabilities--e.g., cross-site scripting, SQL injection, access control, and business logic errors. The primary reason is failure to focus on establishing strong defenses against threats, merely doing patch work, and leaving the weaknesses unguarded.
This deck provides a detailed overview of Rugged software, its development, and the guiding principles to enable a Rugged Culture of Security. The 10 guiding principles include:
1. Constant Attacks
2. Education
3. Security Hygiene
4. Continuous Improvement
5. Zero-defect Approach
6. Reusable Tools
7. Unified Team
8. Testing
9. Threat Modeling
10. Peer Reviews
The slide deck also includes some slide templates for you to use in your own business presentations.
Similar to Modeling enterprise risk management and secutity with the archi mate language (20)
Multi-Agent System (MAS) monitoring solutions are designed for a plethora of usage topics. Existing approach mostly used cloned back-end architectures while front-end monitoring interface tends to constitute the real specificity of the solution. These interfaces are recurrently structured around three dimensions: access to informed knowledge, agent’s behavioural rules, and restitution of real-time states of specific system sector. In this paper, we propose prototyping a sector-agnostic MAS platform (Smart-X) which gathers in an integrated and independent platform all the functionalities required to monitor and to govern a wide range of sector specific environments. For illustration and validation purposes, the use of Smart-X is introduced and explained with a smart-mobility case study.
Aligning the business operations with the appropriate IT infrastructure is a challenging and critical activity. Without efficient business/IT alignment, the companies face the risk not to be able to deliver their business services satisfactorily and that their image is seriously altered and jeopardized. Among the many challenges of business/IT alignment is the access rights management which should be conducted considering the rising governance needs, such as taking into account the business actors' responsibility. Unfortunately, in this domain, we have observed that no solution, model and method, fully considers and integrates the new needs yet. Therefore, the paper proposes firstly to define an expressive Responsibility metamodel, named ReMMo, which allows representing the existing responsibilities at the business layer and, thereby, allows engineering the access rights required to perform these responsibilities, at the application layer. Secondly, the Responsibility metamodel has been integrated with ArchiMate® to enhance its usability and benefits from the enterprise architecture formalism. Finally, a method has been proposed to define the access rights more accurately, considering the alignment of ReMMo and RBAC. The research was realized following a design science and action design based research method and the results have been evaluated through an extended case study at the Hospital Center in Luxembourg.
This document proposes an innovative systemic approach to risk management across interconnected sectors. It suggests using enterprise architecture models to manage cross-sector risks in Luxembourg's complex ICT ecosystem. The approach would provide regulators an overview of all players and systems, as well as models of different sectors to analyze collected data and risks at a national level, fostering accurate and reactive risk mitigation across economic domains.
This document proposes extending the HL7 standard with a responsibility perspective to better manage access rights to patient health records. It presents the ReMMo responsibility metamodel, which defines actors' responsibilities and associated access rights. The paper aims to align ReMMo with the HL7-based eSanté healthcare platform model in Luxembourg to semantically enhance access controls based on users' real responsibilities rather than just roles. It will first map concepts between the two models, then evaluate the alignment through a prototype applying inference rules.
This document presents a study that aims to develop and validate a responsibility model to improve IT governance. It analyzes concepts of responsibility from literature and frameworks like COBIT. The researchers developed a responsibility model with key concepts like obligation, accountability, right, and commitment. They then compare this model to COBIT's representation of responsibility to identify areas for potential enhancement, like adding concepts that COBIT lacks. The document illustrates how the responsibility model could be used to refine COBIT's process for identifying system owners and their responsibilities.
This document proposes an innovative approach called SIM (Secure Identity Management) that aims to make access management policies closer aligned with business objectives. It does this in two ways:
1) By focusing the policy engineering process on business goals and responsibilities defined in processes, using concepts from the ISO/IEC 15504 standard. This links capabilities and accountabilities to process outcomes and work products.
2) By defining a multi-agent system architecture to automate the deployment of policies across heterogeneous IT components and devices. The agents provide autonomy and ability to adapt rapidly according to context.
The approach was prototyped using open source components and aims to improve how access rights are defined according to business needs and deployed across an organization
This document proposes a methodological approach for specifying services and analyzing service compliance considering the responsibility dimension of stakeholders. The approach includes a product model and process model. The product model has three layers: an informational layer describing service context and concepts, an organizational layer describing business rules and roles, and a responsibility dimension layer linking the two. The process model outlines steps for service architects to identify context, define concepts and rules, specify services, and analyze compliance. The approach is illustrated with an example of managing access rights for sensitive healthcare data exchange between organizations.
This document discusses integrating responsibility aspects into service engineering for e-government. It proposes a multi-layered approach including an ontological layer defining legal concepts, an organizational layer describing roles and stakeholders, an informational layer representing data structures and integrity constraints, and a technical layer representing IT components. A responsibility meta-model is also introduced to align responsibilities across these layers and facilitate interoperability between services that share data. The approach aims to ensure service compliance and manage risks associated with e-government services.
1) The document proposes a dynamic approach for assigning functions and responsibilities to agents in a multi-agent system for critical infrastructure management.
2) The approach uses an agent's reputation, which is based on past performance, to determine which agents receive which responsibilities as crisis situations change over time.
3) Assigning responsibilities dynamically based on reputation allows the system to continue operating effectively if an agent becomes isolated or has reduced capabilities during a crisis.
This document proposes a responsibility modeling language (ReMoLa) to align access rights with business process requirements. ReMoLa is a responsibility-centered meta-model that integrates concepts from the business and technical layers, with the concept of employee responsibility bridging the two. It incorporates four types of obligations from the COBIT framework to refine employee responsibilities and better assign access rights. ReMoLa maps responsibilities to roles in the RBAC model to leverage its advantages for access right management while ensuring responsibilities align with business tasks and employee commitment.
The document describes the NOEMI assessment methodology, which was developed as part of a research project to help very small enterprises (VSEs) improve their IT practices. The methodology aims to assess VSEs' IT capabilities in order to facilitate collaborative IT management across organizations. It was designed to be aligned with common IT standards like ISO/IEC 15504 and ITIL, but adapted specifically for VSEs. The methodology has been tested through several case studies with VSEs in Luxembourg, with promising results.
This document provides a preliminary literature review of policy engineering methods related to the concept of responsibility. It summarizes key access control models and discusses how they address concepts like capability, accountability, and commitment. The document also reviews engineering methods and how they incorporate responsibility considerations. The overall goal is to orient further research towards a new policy model and engineering method that more fully addresses stakeholder responsibility.
This document proposes an extension of the ArchiMate enterprise architecture framework to model multi-agent systems for critical infrastructure governance. The authors develop a responsibility-driven policy concept and metamodel layers to represent agent behavior and organizational policies across technical, application, and organizational layers. The approach is illustrated through a case study of a financial transaction processing system.
This document summarizes an experimental prototype of the OpenSST protocol for secured electronic transactions. OpenSST was developed to achieve high security, simplicity in software engineering, and compatibility with existing standards. The prototype uses OpenSST for the authorization portion of electronic payments in an e-business clearing solution. It describes the OpenSST message format and types, and discusses how OpenSST is implemented in the prototype's three-element architecture of an OpenSST proxy, reverse proxy, and server.
This document proposes an automatic reaction strategy for critical infrastructure SCADA systems. It defines a three-layer metamodel for modeling SCADA components and two types of policies (cognitive and permissive) that govern component behavior. It then presents a two-phase method for identifying these policies from the SCADA architecture and formalizing them to support an automatic reaction strategy. This strategy is modeled as an integral part of the SCADA architecture using the defined metamodel and policy identification method. It includes organizational and application layers with main actors, strategies, and components that realize the reaction policies based on expected automation levels.
This document discusses the NOEMI model, a collaborative management model for ICT processes in SMEs. The model was developed by the Centre Henri Tudor and tested with a cluster of 8 partner SMEs. Key aspects of the model include defining ICT activities across 5 domains, assessing each SME's capabilities, and having an operational team manage activities for the cluster under a coordination committee. The experiment showed improved cost control, management, and partner satisfaction compared to alternatives like outsourcing or hiring individual IT staff. The research is now ready for market transfer as the successful model is adopted long-term by participating SMEs.
The document proposes an agent-based architecture for multi-level security incident reaction in distributed telecommunication networks. The architecture has three levels: a low level interface with the infrastructure, an intermediate level using multi-agent systems to correlate alerts and deploy reactions across domains, and a high level for global supervision and policy management. The architecture was designed based on requirements like scalability, availability, autonomy, and robust reaction and alert management across distributed systems. It was successfully tested for implementing data access control policies.
This document proposes a multi-agent architecture for incident reaction in information system security. The architecture has three layers - low level interacts directly with the infrastructure, intermediate level correlates alerts and deploys reaction actions using multi-agent systems, and high level provides supervision and manages business policies. The architecture was tested for data access control and aims to quickly and efficiently react to attacks while ensuring policy compliance. The document discusses requirements like scalability, autonomy, and global supervision. It also describes the key components of alert management, reaction decision making, and policy definition/deployment to implement the architecture using a multi-agent approach.
More from Luxembourg Institute of Science and Technology (20)
Evaluation and Identification of J'BaFofi the Giant Spider of Congo and Moke...MrSproy
ABSTRACT
The J'BaFofi, or "Giant Spider," is a mainly legendary arachnid by reportedly inhabiting the dense rain forests of
the Congo. As despite numerous anecdotal accounts and cultural references, the scientific validation remains more elusive.
My study aims to proper evaluate the existence of the J'BaFofi through the analysis of historical reports,indigenous
testimonies and modern exploration efforts.
This presentation offers a general idea of the structure of seed, seed production, management of seeds and its allied technologies. It also offers the concept of gene erosion and the practices used to control it. Nursery and gardening have been widely explored along with their importance in the related domain.
Discovery of An Apparent Red, High-Velocity Type Ia Supernova at 𝐳 = 2.9 wi...Sérgio Sacani
We present the JWST discovery of SN 2023adsy, a transient object located in a host galaxy JADES-GS
+
53.13485
−
27.82088
with a host spectroscopic redshift of
2.903
±
0.007
. The transient was identified in deep James Webb Space Telescope (JWST)/NIRCam imaging from the JWST Advanced Deep Extragalactic Survey (JADES) program. Photometric and spectroscopic followup with NIRCam and NIRSpec, respectively, confirm the redshift and yield UV-NIR light-curve, NIR color, and spectroscopic information all consistent with a Type Ia classification. Despite its classification as a likely SN Ia, SN 2023adsy is both fairly red (
�
(
�
−
�
)
∼
0.9
) despite a host galaxy with low-extinction and has a high Ca II velocity (
19
,
000
±
2
,
000
km/s) compared to the general population of SNe Ia. While these characteristics are consistent with some Ca-rich SNe Ia, particularly SN 2016hnk, SN 2023adsy is intrinsically brighter than the low-
�
Ca-rich population. Although such an object is too red for any low-
�
cosmological sample, we apply a fiducial standardization approach to SN 2023adsy and find that the SN 2023adsy luminosity distance measurement is in excellent agreement (
≲
1
�
) with
Λ
CDM. Therefore unlike low-
�
Ca-rich SNe Ia, SN 2023adsy is standardizable and gives no indication that SN Ia standardized luminosities change significantly with redshift. A larger sample of distant SNe Ia is required to determine if SN Ia population characteristics at high-
�
truly diverge from their low-
�
counterparts, and to confirm that standardized luminosities nevertheless remain constant with redshift.
Microbial interaction
Microorganisms interacts with each other and can be physically associated with another organisms in a variety of ways.
One organism can be located on the surface of another organism as an ectobiont or located within another organism as endobiont.
Microbial interaction may be positive such as mutualism, proto-cooperation, commensalism or may be negative such as parasitism, predation or competition
Types of microbial interaction
Positive interaction: mutualism, proto-cooperation, commensalism
Negative interaction: Ammensalism (antagonism), parasitism, predation, competition
I. Mutualism:
It is defined as the relationship in which each organism in interaction gets benefits from association. It is an obligatory relationship in which mutualist and host are metabolically dependent on each other.
Mutualistic relationship is very specific where one member of association cannot be replaced by another species.
Mutualism require close physical contact between interacting organisms.
Relationship of mutualism allows organisms to exist in habitat that could not occupied by either species alone.
Mutualistic relationship between organisms allows them to act as a single organism.
Examples of mutualism:
i. Lichens:
Lichens are excellent example of mutualism.
They are the association of specific fungi and certain genus of algae. In lichen, fungal partner is called mycobiont and algal partner is called
II. Syntrophism:
It is an association in which the growth of one organism either depends on or improved by the substrate provided by another organism.
In syntrophism both organism in association gets benefits.
Compound A
Utilized by population 1
Compound B
Utilized by population 2
Compound C
utilized by both Population 1+2
Products
In this theoretical example of syntrophism, population 1 is able to utilize and metabolize compound A, forming compound B but cannot metabolize beyond compound B without co-operation of population 2. Population 2is unable to utilize compound A but it can metabolize compound B forming compound C. Then both population 1 and 2 are able to carry out metabolic reaction which leads to formation of end product that neither population could produce alone.
Examples of syntrophism:
i. Methanogenic ecosystem in sludge digester
Methane produced by methanogenic bacteria depends upon interspecies hydrogen transfer by other fermentative bacteria.
Anaerobic fermentative bacteria generate CO2 and H2 utilizing carbohydrates which is then utilized by methanogenic bacteria (Methanobacter) to produce methane.
ii. Lactobacillus arobinosus and Enterococcus faecalis:
In the minimal media, Lactobacillus arobinosus and Enterococcus faecalis are able to grow together but not alone.
The synergistic relationship between E. faecalis and L. arobinosus occurs in which E. faecalis require folic acid
The Limited Role of the Streaming Instability during Moon and Exomoon FormationSérgio Sacani
It is generally accepted that the Moon accreted from the disk formed by an impact between the proto-Earth and
impactor, but its details are highly debated. Some models suggest that a Mars-sized impactor formed a silicate
melt-rich (vapor-poor) disk around Earth, whereas other models suggest that a highly energetic impact produced a
silicate vapor-rich disk. Such a vapor-rich disk, however, may not be suitable for the Moon formation, because
moonlets, building blocks of the Moon, of 100 m–100 km in radius may experience strong gas drag and fall onto
Earth on a short timescale, failing to grow further. This problem may be avoided if large moonlets (?100 km)
form very quickly by streaming instability, which is a process to concentrate particles enough to cause gravitational
collapse and rapid formation of planetesimals or moonlets. Here, we investigate the effect of the streaming
instability in the Moon-forming disk for the first time and find that this instability can quickly form ∼100 km-sized
moonlets. However, these moonlets are not large enough to avoid strong drag, and they still fall onto Earth quickly.
This suggests that the vapor-rich disks may not form the large Moon, and therefore the models that produce vaporpoor disks are supported. This result is applicable to general impact-induced moon-forming disks, supporting the
previous suggestion that small planets (<1.6 R⊕) are good candidates to host large moons because their impactinduced disks would likely be vapor-poor. We find a limited role of streaming instability in satellite formation in an
impact-induced disk, whereas it plays a key role during planet formation.
Unified Astronomy Thesaurus concepts: Earth-moon system (436)
Rodents, Birds and locust_Pests of crops.pdfPirithiRaju
Mole rat or Lesser bandicoot rat, Bandicotabengalensis
•Head -round and broad muzzle
•Tail -shorter than head, body
•Prefers damp areas
•Burrows with scooped soil before entrance
•Potential rat, one pair can produce more than 800 offspringsin one year
Physics Investigatory Project on transformers. Class 12thpihuart12
Physics investigatory project on transformers with required details for 12thes. with index, theory, types of transformers (with relevant images), procedure, sources of error, aim n apparatus along with bibliography🗃️📜. Please try to add your own imagination rather than just copy paste... Hope you all guys friends n juniors' like it. peace out✌🏻✌🏻
Signatures of wave erosion in Titan’s coastsSérgio Sacani
The shorelines of Titan’s hydrocarbon seas trace flooded erosional landforms such as river valleys; however, it isunclear whether coastal erosion has subsequently altered these shorelines. Spacecraft observations and theo-retical models suggest that wind may cause waves to form on Titan’s seas, potentially driving coastal erosion,but the observational evidence of waves is indirect, and the processes affecting shoreline evolution on Titanremain unknown. No widely accepted framework exists for using shoreline morphology to quantitatively dis-cern coastal erosion mechanisms, even on Earth, where the dominant mechanisms are known. We combinelandscape evolution models with measurements of shoreline shape on Earth to characterize how differentcoastal erosion mechanisms affect shoreline morphology. Applying this framework to Titan, we find that theshorelines of Titan’s seas are most consistent with flooded landscapes that subsequently have been eroded bywaves, rather than a uniform erosional process or no coastal erosion, particularly if wave growth saturates atfetch lengths of tens of kilometers.
Discovery of Merging Twin Quasars at z=6.05Sérgio Sacani
We report the discovery of two quasars at a redshift of z = 6.05 in the process of merging. They were
serendipitously discovered from the deep multiband imaging data collected by the Hyper Suprime-Cam (HSC)
Subaru Strategic Program survey. The quasars, HSC J121503.42−014858.7 (C1) and HSC J121503.55−014859.3
(C2), both have luminous (>1043 erg s−1
) Lyα emission with a clear broad component (full width at half
maximum >1000 km s−1
). The rest-frame ultraviolet (UV) absolute magnitudes are M1450 = − 23.106 ± 0.017
(C1) and −22.662 ± 0.024 (C2). Our crude estimates of the black hole masses provide log 8.1 0. ( ) M M BH = 3
in both sources. The two quasars are separated by 12 kpc in projected proper distance, bridged by a structure in the
rest-UV light suggesting that they are undergoing a merger. This pair is one of the most distant merging quasars
reported to date, providing crucial insight into galaxy and black hole build-up in the hierarchical structure
formation scenario. A companion paper will present the gas and dust properties captured by Atacama Large
Millimeter/submillimeter Array observations, which provide additional evidence for and detailed measurements of
the merger, and also demonstrate that the two sources are not gravitationally lensed images of a single quasar.
Unified Astronomy Thesaurus concepts: Double quasars (406); Quasars (1319); Reionization (1383); High-redshift
galaxies (734); Active galactic nuclei (16); Galaxy mergers (608); Supermassive black holes (1663)
JAMES WEBB STUDY THE MASSIVE BLACK HOLE SEEDSSérgio Sacani
The pathway(s) to seeding the massive black holes (MBHs) that exist at the heart of galaxies in the present and distant Universe remains an unsolved problem. Here we categorise, describe and quantitatively discuss the formation pathways of both light and heavy seeds. We emphasise that the most recent computational models suggest that rather than a bimodal-like mass spectrum between light and heavy seeds with light at one end and heavy at the other that instead a continuum exists. Light seeds being more ubiquitous and the heavier seeds becoming less and less abundant due the rarer environmental conditions required for their formation. We therefore examine the different mechanisms that give rise to different seed mass spectrums. We show how and why the mechanisms that produce the heaviest seeds are also among the rarest events in the Universe and are hence extremely unlikely to be the seeds for the vast majority of the MBH population. We quantify, within the limits of the current large uncertainties in the seeding processes, the expected number densities of the seed mass spectrum. We argue that light seeds must be at least 103 to 105 times more numerous than heavy seeds to explain the MBH population as a whole. Based on our current understanding of the seed population this makes heavy seeds (Mseed > 103 M⊙) a significantly more likely pathway given that heavy seeds have an abundance pattern than is close to and likely in excess of 10−4 compared to light seeds. Finally, we examine the current state-of-the-art in numerical calculations and recent observations and plot a path forward for near-future advances in both domains.
Presentation of our paper, "Towards Quantitative Evaluation of Explainable AI Methods for Deepfake Detection", by K. Tsigos, E. Apostolidis, S. Baxevanakis, S. Papadopoulos, V. Mezaris. Presented at the ACM Int. Workshop on Multimedia AI against Disinformation (MAD’24) of the ACM Int. Conf. on Multimedia Retrieval (ICMR’24), Thailand, June 2024. https://doi.org/10.1145/3643491.3660292 https://arxiv.org/abs/2404.18649
Software available at https://github.com/IDT-ITI/XAI-Deepfakes
Modeling enterprise risk management and secutity with the archi mate language
1. Modeling Enterprise Risk
Management and Security
with the ArchiMate®
Language
A White Paper by:
Iver Band, EA Principals
Wilco Engelsman, BiZZdesign
Christophe Feltus, Luxembourg Institute of Science and Technology
Sonia González Paredes, Dux Diligens
Jim Hietala, The Open Group
Henk Jonkers, BiZZdesign
Sebastien Massart, Arismore
January, 2015
3. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 3
Table of Contents
Introduction.....................................................................................6
Risk and Security Standards, Frameworks, and Concepts................12
Introduction to the ArchiMate Standard .........................................19
Modeling Risk and Security Aspects with the ArchiMate Language .22
Case Studies and Examples.............................................................27
Summary and Conclusions .............................................................37
References......................................................................................38
About the Authors..........................................................................40
About The Open Group..................................................................42
4. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 4
Boundaryless Information Flow
achieved through global interoperability
in a secure, reliable, and timely manner
Executive Summary
Enterprise Architects can use the ArchiMate®
language to model Enterprise Risk
Management (ERM) and security concepts and relationships. This widely accepted
open standard provides the modeling constructs to describe and interconnect business
and technical architectures. Applying the ArchiMate language to represent risk and
security concepts results in the ideal vehicle to consider these aspects in an integral
way. The ArchiMate language fits well with other Enterprise Architecture (EA)
frameworks and standards, such as the TOGAF®
standard and the Zachman
framework, as well as enterprise security management frameworks such as the
Sherwood Applied Business Security Architecture (SABSA).
Through its Motivation extension, the ArchiMate language makes it possible to link
control measures to security requirements, principles, and goals, as well as to the
results of a risk analysis. On the other hand, ArchiMate models can be linked to
design languages for business processes and IT solutions such as BPMN and UML.
These linkages enable precise gathering of a set of broadly accepted risk and security
concepts, analysis of their semantics, and consensus regarding the most important
ones of the full scope of enterprise risk.
This White Paper, a joint project of The Open Group ArchiMate Forum and The
Open Group Security Forum, demonstrates this approach and identifies opportunities
for future work that would enhance it.
5. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 5
After summarizing the ArchiMate 2.1 language, this White Paper reviews relevant
standards and frameworks, including the TOGAF framework, the COSO ERM
framework, the SABSA framework, and The Open Group Risk Taxonomy (O-RT)
standard, upon which the Open FAIR risk analysis method is based. From these well-
established paradigms, this White Paper extracts a broadly accepted set of risk and
security concepts for expression in the ArchiMate language. These concepts cover:
Vulnerability analysis: Asset at risk, vulnerability
Risk management: Risk, threat, threat agent, loss event
Security deployment: Control objective, control measure
Classification: Risk domain
This White Paper examines three approaches to modeling risk and security concepts.
1. Using only the standard ArchiMate 2.1 language
2. Defining risk and security-specific specializations of ArchiMate 2.1
concepts
3. Defining risk and security concepts that complement ArchiMate 2.1
language concepts
This White Paper demonstrates, through concept mapping and case studies, that
options 1 and 2 suffice for the majority of common risk and security concepts. The
concepts that cannot readily be mapped, domain and operational policy, are also not
specific to risk and security; they are specializations of concepts useful in a broader
range of EA efforts.
Enterprise and security architects as well as risk and security analysts can benefit
from this White Paper, which supports The Open Group vision of Boundaryless
Information Flow™ by showing how ArchiMate models can help enterprises manage
the myriad risks of our pervasively interconnected world while embracing its myriad
opportunities.
6. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 6
Introduction
The importance of Enterprise Risk Management (ERM) and security rises with the progress of globalization
and growth of the Internet. An increasing number of organizations interact with consumers and trading
partners around the world, and are therefore exposed to an increasing variety of risks. Furthermore, they
interact using electronic communications that can be compromised or abused. Many organizations are
therefore facing complex risk scenarios that demand sophisticated planning and execution to protect their
interests. Therefore, the ability to identify and manage risk has become a key priority in organizations no
matter their size, industry, or region. Organizations need to understand the variables that affect their
operations, so describing, classifying, managing, and mitigating risk factors is very important.
Enterprise Architecture (EA) builds transformative capabilities from people, processes, technology, and
information. All of these capabilities can be threatened by diverse factors. Therefore, the assets that compose
them must be protected. An EA approach that promotes systematic analysis, common understanding, and
well-defined approaches to complex situations can therefore assist in the management of enterprise risk and
security.
Enterprise Architects must help organizations manage risk through architectures that help avoid, transfer,
mitigate, or accept adverse risks, because risks are not only inherent in the baseline state of every enterprise;
they are inherent in any opportunities that the enterprise may embrace. ERM and security are therefore
concerns that span all EA domains. Enterprise Architects can support ERM practices by:
• Understanding risk categories, the assets exposed to risks in each category, and the relationships between
different risks
• Defining risk assessment methods
• Guiding risk management processes
• Integrating ERM into the EA practice
Risk and security models help organizations develop guidance and take action to embrace opportunity and
manage risk. This White Paper examines a selection of well-established paradigms for risk and security
modeling and analysis, extracts a set of core concepts from them, and maps most of the concepts to
ArchiMate language elements.
This White Paper analyzes a representative sample of authoritative ERM and security frameworks and
methods in order to gather a set of broadly accepted risk and security concepts, analyze their semantics, and
reach consensus regarding the most important ones. The analyzed frameworks include the Casualty Actuary
Society (CAS) ERM overview [10], the Committee of Sponsoring Organizations of the Treadway
Commission (COSO) framework [9], Factor Analysis of Information Risk (Open FAIR) [3] and the
Sherwood Applied Business Security Architecture (SABSA) [7,8]. This White Paper then models the
Coldhard Steel case study from the CAS ERM overview, along with some original information security
extensions. Based on the results of these modeling exercises, this White Paper describes the capabilities of
the ArchiMate 2.1 language as specified, and as enhanced through its specified extension mechanisms
(specialization of concepts, both from the ArchiMate core and the Motivation extension, and adding risk and
security-specific attributes).
7. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 7
The TOGAF and ArchiMate Approach to Security
The TOGAF standard [20] presents security architecture as one of the important issues and organizational
practices for Enterprise Architects. In the TOGAF Architecture Development Method (ADM), business
requirements and drivers for security are mentioned as important issues for Phases A and B. The ADM
focuses on generating requirements related to security, as well as for risk, by explaining how an
organization’s attitude towards risk determines the kind of protection that an asset needs and what the
resulting security requirements are. It also mentions the need to define asset stewardship, especially for
information assets, and the need to perform risk assessments and relate security to them.
The section of the TOGAF standard providing security guidance (Chapter 31: Risk Management) is mainly
focused on security considerations and requirements for an EA iteration applying the ADM. It identifies
specific areas of concern for security such as authentication, authorization, auditing, assurance, availability,
asset protection, and administration, and relates them to risk management. All of these aspects are mainly
presented as IT functions related to the information security discipline.
The TOGAF standard specifies security architecture viewpoints and frameworks, and also provides very
general guidance for applying the Architecture Content Framework (ACF) and the TOGAF Metamodel to
security views and patterns. The TOGAF standard presents examples like the data security diagram. In
Chapter 35 (Architectural Artifacts) some basic patterns for security views are presented, and they are
primarily focused on information systems security.
Regarding security management, the ADM recommends the integration of the EA effort with the security
management organizational function along with other adjacent functions such as risk, project, and portfolio
management.
This White Paper will extend the existing risk and security content of the TOGAF standard using relevant
industry standards and leveraging the ArchiMate visual modeling language to:
• Cover risk assessment and protection of assets beyond information security
• Provide guidance and detailed tools and techniques for constructing specific models, viewpoints, and
patterns that help practitioners to develop security architecture models
• Identify modeling patterns for functions such as authentication and authorization, security auditing, and
monitoring
• Provide elements and mapping to the TOGAF ACF and Metamodel
The ArchiMate 2.1 specification makes very brief mentions of risk and security. It identifies risk and security
as an important EA aspect that the language does not explicitly address, although it identifies the
Infrastructure, Implementation, and Deployment and Project Viewpoints as useful for addressing risk or
security concerns.
The TOGAF framework and the ArchiMate language can be extended and combined to help Enterprise
Architects address risk and security. This White Paper provides specific guidance for risk and security
modeling by extending the TOGAF standard and using the ArchiMate language.
8. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 8
Defining ERM and Security Together
This section gathers definitions for ERM, security, and related terms. It first summarizes a selection of
leading definitions of ERM.
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) is a coalition of
professional organizations for accounting, auditing, and financial management. COSO issued its Enterprise
Risk Management – Integrated Framework [9] in September 2004. The COSO ERM Framework includes key
principles and concepts, a vocabulary, and guidance for evaluating and implementing ERM.
COSO defines ERM as:
“… a process, effected by an entity’s board of directors, management, and other personnel, applied in
strategy setting and across the enterprise, designed to identify potential events that may affect the entity, and
manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of
entity objectives.”
Figure 1 assembles the definitions in this section into a generic ERM model. An enterprise contains
stakeholders concerned with risk, who engage in ERM activity that assesses and manages risk.
Figure 1: Generic Risk Model
Here is the Casualty Actuary Society (CAS) [10] definition:
“ERM is the discipline by which an organization in any industry assesses, controls, exploits, finances, and
monitors risks from all sources for the purpose of increasing the organization’s short- and long-term value to
its stakeholders.”
The Institute of Risk Management (IRM) [4] defines risk management (clearly in an enterprise context) as
follows:
9. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 9
“Risk management is a central part of any organization’s strategic management. It is the process whereby
organizations methodically address the risks attaching to their activities with the goal of achieving sustained
benefit within each activity and across the portfolio of all activities.”
Each of these three ERM definitions discusses an enterprise engaging in risk-related activities that support or
directly achieve organizational objectives. Each definition at least implies the existence of risk assessments,
as well stakeholders concerned with risk. Therefore, they align with the ERM model in Figure 1.
This White Paper deals with modeling security as well as ERM. In relation to ERM, what does “security”
mean? The Oxford English Dictionary (OED) [5] has a number of definitions that match typical goals of
ERM:
• The state or condition of being or feeling secure
• Freedom from danger or threat:
o The safety of an organization, establishment, or building from espionage, criminal activity, illegal
entrance, or escape
o With reference to encryption, or telecommunications or computer systems: the state of being
protected from unauthorized access; freedom from the risk of being intercepted, decoded, tapped,
etc.
The OED also has a number of definitions that match the behaviors and mechanisms of ERM:
• Something which secures or makes safe …
• A protection or defense against, from, for something …
• Grounds for regarding something as secure, safe, or certain; an assurance, safeguard, guarantee
• … any checks and procedures intended to keep a person, place, or thing secure
The OED reference to “encryption … telecommunication or computer systems” addresses information
security. The SANS Institute [12] defines information security as:
“… the processes and methodologies which are designed and implemented to protect print, electronic, or any
other form of confidential, private, and sensitive information or data from unauthorized access, use, misuse,
disclosure, destruction, modification, or disruption …”
This definition is closely related to the well-known Confidentiality, Integrity, and Availability (CIA) model
used for developing security policy.
In summary, information security is part of security, which is in turn part of ERM, and these domains
encompass related goals. Figure 2 builds on Figure 1 to show the relationship between these domains.
10. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 10
Figure 2: Security and Information Security as Specializations of ERM
COSO identifies four types of objectives for the continuous, enterprise-wide risk management activity that it
specifies:
• Strategic objectives are high-level and aligned with the enterprise’s mission.
• Operations objectives are concerned with effective and efficient use of resources.
• Reporting objectives are concerned with reliable reporting.
• Compliance objectives are concerned with applicable laws and regulations.
To specify and realize these activities, COSO defines seven types of activities:
• Objective Setting – Management must have a process in place to set objectives consistent with both the
mission of the enterprise and its appetite for risk.
• Event Identification – Enterprises must identify both internal and external events, and distinguish
between the risks and opportunities that they pose. Opportunities should be used for strategy
development or objective setting.
• Risk Assessment – Enterprises must analyze and consider the likelihood and impact of risks, both
11. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 11
inherently and residually.
• Risk Response – Enterprises must determine how to respond to risks, which may be avoided, accepted,
reduced, or shared, with actions based on organizational risk tolerance and appetite.
• Control – Policies and procedures must be established and implemented for effective responses to risk.
• Information and Communication – Timely identification, capture, and communication of relevant
information across, up, and down organizations enables people to carry out their risk management
responsibilities.
Figure 3 below models these activities as functions carried out by enterprises (entities, in COSO ERM
parlance) to realize risk management objectivities.
Figure 3: COSO ERM Model
12. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 12
Risk and Security Standards, Frameworks, and Concepts
This section identifies the risk and security concepts in the most common frameworks, including the Risk
Taxonomy (O-RT) standard, the TOGAF security view risk classification, and the SABSA framework.
The breadth of ERM requires a structured approach to risk analysis along with a method of organizing the
myriad risks facing every enterprise. The FAIR Risk Taxonomy defines and hierarchically classifies the
elements of risk.
The Open Group Risk Taxonomy Standard/Open FAIR
This section summarizes The Open Group Risk Taxonomy (O-RT) standard, also known as the Open FAIR
Risk Taxonomy (a part of the Open FAIR Body of Knowledge). This Open Group standard provides a
definition and taxonomy for information security risk, as well as information regarding how to use the
taxonomy. It describes the main factors that drive risk, their definitions, and relationships, so it provides a
guideline for defining the basic terms for defining and measuring risk using a single logical and rational
taxonomical framework. Although Open FAIR has its roots in information security risk, it can be applied to
analyzing all kinds of risk.
The risk taxonomy overview is presented in Figure 4, which is taken from the O-RT standard.
Figure 4: Open FAIR Risk Taxonomy [3]
In this taxonomy, “risk” is defined as the probable frequency and probable magnitude of future loss, which
means that the risk definition is dependent on two factors: loss event frequency and probable loss magnitude.
Then, recursively, each one of the rest of the factors is defined until the lower branches for the model are
reached. For example, in the left branch of the model, the loss event frequency is dependent on threat event
frequency and vulnerability.
All of the elements of the Open FAIR Risk Taxonomy refer to organizational assets that are being threatened
by different environmental factors or agents that can be either internal or external to the organization. This
risk exposure depends on the time interval in which the asset is being exposed and the vulnerability level that
the asset might have. The right side of the model considers the risk impact, which depends on probable loss
magnitude, which in turn depends on a hierarchy of loss factors.
13. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 13
Classifying Risks and Risk Assessments
While the Open FAIR Risk Taxonomy can be used to decompose and analyze a single risk, there are other
risk taxonomies that seek to classify all risks within a particular domain. For example, the CAS ERM
overview identifies four types of enterprise risk [10]:
• Hazard Risks include risks from fire and other property damage, windstorm and other natural perils, theft
and other crime, personal injury, business interruption, disease and disability, as well as from liability
claims.
• Financial Risks include risks from price, liquidity, credit, inflation and purchasing power, as well as from
hedging and basis.
• Operational Risks include risks from business operations, empowerment mechanisms such as leadership
and change readiness, information technology issues such as relevance and availability, as well as from
problems with information and business reporting.
• Strategic Risks include risks from reputational damage, competition, customer wants, demographic and
social and cultural trends, technological innovation and capital availability, as well as from regulatory
and political trends.
Figure 5 represents the top two levels of this classification of enterprise risk.
Figure 5: CAS Classification of Enterprise Risk
Similarly, the American Society for Healthcare Risk Management (ASHRM) has developed an enterprise
risk taxonomy for the healthcare domain [0], which is summarized in Figure 6 below.
Figure 6: ASHRM Common Healthcare Risk Domains
There could be several types of risks; some of them are more closely related with the EA development such
as the operational, compliance, and security risks; however, other risk categories such as financial, project,
organizational change, and system risk can also influence and be influenced by the EA practice.
14. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 14
Sherwood Applied Business Security Architecture (SABSA)
The SABSA matrix (framework) is a structure that is very similar to the Zachman framework, but
specifically aimed at risk and security aspects. This matrix defines relevant viewpoints for risk and security
modeling, in a systematic way. SABSA does not define specific modeling concepts, but the matrix does
describe a wide variety of aspects that a modeler should be able to express. The exact content of each of the
“cells” of the matrix is open to interpretation.
Figure 7: SABSA Framework [7,8]
In the context of this White Paper, mainly the upper three layers are relevant. The lower three layers are
concerned with the detailed design of security controls. Some of the views are regular ArchiMate views that
serve as the context for risk and security aspects, while others address specific security issues.
The table below summarizes the (new or specialized) concepts identified to populate the cells of the top three
layers of the SABSA matrix. Concepts written in italics denote concepts that are already part of the
ArchiMate language (core and extensions).
15. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 15
Assets Motivation Process People Location Time
Contextual
Architecture
business
asset;
goal
opportunity;
threat; risk;
stakeholder;
driver, goal
business
process
business
actor,
business role
location;
network
plateau,
requirement
Conceptual
Architecture
business
attribute
profile
(business
strategy;
business
driver;
business
asset; goal;
objective)
business policy;
control
objective;
(goal; principle;
requirement)
security
strategy
security entity
(business
role; business
actor;
application
component)
(security
domain);
security
element
(security entity;
security object);
security policy
lifecycle
Logical
Architecture
information
asset
policy, policy
statement
(requirement);
policy
procedure
(process);
policy, guideline
business
process;
business
service
trust;
entity schema
rule;
object
network
domain,
people/actor
role
information
resource
service;
application
component;
application
function;
infrastructure
service;
network,
infrastructure
function;
information
domain;
application
domain;
people domain
plateau,
program,
project
Figure 8: Main Concepts in SABSA Framework Layers 1 to 31
The SABSA approach toward risk factors considers both the risk of adverse occurrences as well as the
prospect of beneficial events. The following ArchiMate model illustrates this approach, in which an asset at
risk can be information, software, tangible organizational assets, human assets, and intangible assets. The two
types of factors that can act against an asset are threats that have to be controlled and also opportunities that
could become beneficial if exploited correctly.
1
Concepts in italics more or less directly map to concepts in the ArchiMate 2.1 specification.
16. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 16
For a threat-based risk the following factors are important and are also mentioned in the Open FAIR Risk
Taxonomy section of this White Paper:
• Threat
• Vulnerability
• Control
Threat management is not sufficient for organizations that want to innovate, enhance the value they deliver,
and grow. Those organizations must also proactively identify events that present opportunities to increase the
value of their assets and enhance their overall capabilities to deliver value to customers. The right side of
Figure 9 depicts this approach, and differentiates it from the threat-centric approach to risk management.
Figure 9: Comparison of Threat Risk and Opportunity Risk Approaches
Information System Security Risk Management (ISSRM) Domain Metamodel
In research performed at Tudor Research Centre, the different concepts of ISSRM and their relationships
have been formalized as a domain metamodel (Figure 10); i.e., a conceptual model depicting the studied
domain [15]. The ISSRM domain model has been established through the analysis of the related literature:
risk management standards, security-related standards, security risk management standards and methods, and
security requirements engineering frameworks (e.g., references [16,17,18]).
The ISSRM domain model is organized in three groups of concepts, as represented in Figure 10:
• Asset-related concepts describe assets and the goals which guarantee asset security.
• Risk-related concepts present how the risk itself is defined.
17. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 17
Risk treatment-related concepts describe what decisions, requirements, and controls should be defined and
implemented in order to mitigate possible risks.
Figure 10: ISSRM Domain Model (Extracted from reference [15])
In this work, the concept of Security Goal merges the concepts of Security Criterion and Security Objective
defined in an initial model. The description of the main concepts of the ISSRM domain model is summarized
in the table below. An extension of the ArchiMate language with these concepts has been proposed in
reference [20].
Concept Description
Asset Anything that has value to the organization and is necessary for achieving its
objectives.
Business Asset Describes information, processes, capabilities, and skills inherent to the business and
core mission of the organization, having value for it.
IS Asset A component of the IS supporting business assets like a database where information
is stored.
Security Goal A property or constraint on business assets describing their security needs, usually
for confidentiality, integrity, and availability.
Risk The combination of a threat with one or more vulnerabilities leading to a negative
impact harming the assets.
Impact The potential negative consequence of a risk that may harm assets of a system or an
organization, when a threat (or the cause of a risk) is accomplished.
Vulnerability A characteristic of an IS asset or group of IS assets that can constitute a weakness or
a flaw in terms of IS security.
18. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 18
Concept Description
Threat A potential attack or incident, which targets one or more IS assets and may lead to
the assets being harmed.
Risk Treatment An intentional decision to treat identified risks.
Security Requirement The refinement of a treatment decision to mitigate the risk.
Control Controls (countermeasures or safeguards) are designed to improve security,
specified by a security requirement, and implemented to comply with it.
19. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 19
Introduction to the ArchiMate Standard
Core Concepts
ArchiMate [2], an Open Group standard, is an open and independent modeling language for EA that is
supported by different tool vendors and consulting firms. It provides uniform representations for diagrams
that describe EAs. Its core concepts (Figure 11) specify three main types of elements that are in turn often
used to represent classes of real-world entities. These element types are:
• Active Structure Elements, which are entities capable of performing behavior
• Behavior Elements, which are units of activity performed by one or more Active Structure Elements
• Passive Structure Elements, upon which Active Structure Elements perform behavior
The ArchiMate language specializes two of these core element types to enable service-oriented architectural
viewpoints:
• Behavior Elements, known as services, are units of functionality that systems expose to their
environments. Services deliver value to their consumers while concealing the internal operations of the
systems that expose them.
• Active Structure Elements, known as Interfaces, are points of access where systems expose one or more
services to their environments.
Figure 11: ArchiMate Core Concepts (Source [2])
Note that, in this diagram, relationships are red using the verb closest to the first element; e.g., an Active
Structure Element uses an Interface, and a Service accesses a Passive Structure Element.
The ArchiMate language contains a core set of relationships that fall into three categories:
• Structural relationships model the structural coherence between structural or behavioral concepts of the
20. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 20
same or different types. They include association, access, used by, realization, assignment, aggregation,
and composition.
• Dynamic relationships model dependencies between behavioral concepts. They include flow and
triggering. In addition, the ArchiMate language enables the derivation of dynamic relationships between
structural elements to which the behavioral functions are assigned. For example, modelers can depict a
flow relationship between two application functions as a flow relationship between separate Application
Components that perform those functions.
• Other relationships are neither structural nor dynamic. They include grouping, junction, and
specialization.
The ArchiMate language defines three main layers based on specializations of its core concepts:
• The Business Layer models products and services available to external customers of the organization that
is being described. These services are realized by business processes performed by business actors.
• The Application Layer provides the Business Layer with application services that are realized by
software applications.
• The Technology Layer provides the infrastructure services such as data processing, storage, and
communications necessary to run applications. These services are realized by hardware and system
software.
The ArchiMate language combines its three layers with its three core element types for a nine-cell framework
(Figure 12).
Figure 12: The ArchiMate Core Framework (Source [2])
Extensions
To its nine-cell core framework, the ArchiMate 2.1 standard adds two extensions:
• The Motivation extension models the elements that motivate enterprise design and operation. Its concepts
include: stakeholder, driver, assessment, goal, requirement, and principle.
21. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 21
• The Implementation and Migration extension models the implementation of all aspects of EAs, as well as
the migration between generations of implemented architectures. Its concepts include: work package,
deliverable, plateau, and gap.
Viewpoints
The ArchiMate language also includes a set of architecture viewpoints and classifies them in two ways:
• Purpose, which may be designing a solution, deciding on a course of action, or informing employees,
customers, or other stakeholders.
• Abstraction levels, which may embody the details needed by stakeholders such as software and process
engineers, the systemic coherence needed by operational managers who must understand key
relationships to solve problems and implement change, or the overview needed by executives, Enterprise
Architects, and others who must make key decisions and manage change.
The ArchiMate Standard as a Modeling Language for the TOGAF Standard
The ArchiMate modeling language, together with its two extensions, can be used to model architectures
developed using the TOGAF ADM. Figure 13 shows the correspondence between the activities of the ADM
phases and the parts of the ArchiMate language.
Figure 13: Correspondence between TOGAF ADM Phases and the ArchiMate Framework (Source [2])
22. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 22
Modeling Risk and Security Aspects with the ArchiMate Language
Business Value of Modeling ERM with the ArchiMate Language
The ArchiMate standard provides the modeling constructs to describe and interconnect the various
architectural domains. Applying the ArchiMate language to represent risk and security concepts results in the
ideal vehicle to consider these aspects in an integral way.
The ArchiMate language is a widely accepted open standard for modeling EA, with a large user base and a
variety of modeling tools that support it. It fits well with other EA frameworks and standards, such as the
TOGAF standard and the Zachman framework, as well as enterprise security management frameworks such
as SABSA.
Through the Motivation extension, the ArchiMate language makes it possible to link control measures to
security requirements, principles, and goals, as well as to the results of a risk analysis. On the other hand,
ArchiMate models can be linked to design languages for business processes and IT solutions (e.g., BPMN
and UML). In this way, full forward and backward traceability between architecture and design is achieved.
This traceability enables the definition of precise relationships between business and information technology
entities, which facilitates cause and effect analysis. The ArchiMate language also allows modelers to define
additional profile attributes for model elements. These attributes can be used to analyze architectures and
determine the impact of architectural change on risk and security concerns. ArchiMate models are therefore
suitable as a basis for both qualitative and quantitative risk and security analysis.
Consolidation of Risk and Security Concepts
This section identifies the common denominator of concepts for risk and security identified in our overview
of standards and frameworks, and which are relevant in the context of EA models. It provides definitions for
these concepts, as well as their main properties.
Risk
• The probable frequency and probable magnitude of future loss [3].
• The potential of loss (an undesirable outcome; however, not necessarily so) resulting from a given action,
activity, and/or inaction, foreseen or unforeseen.
• A number of risk metrics are commonly applied, such as [3] loss event frequency and probable loss
magnitude.
• Furthermore, a distinction may be made between:
o Initial risk: before mitigation
o Residual risk: after mitigation
Loss Event
Any circumstance that causes a loss or damage to an asset.
23. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 23
Threat
A possible danger that might exploit a vulnerability to breach security and thus cause possible harm. The
term is ambiguous, as it can refer to a threatening circumstance, an entity capable of causing harm (threat
entity), or the actual event that may cause harm (threat event). Therefore, we also introduce the more specific
concepts:
• Threat agent: Anything – for example, an object, substance, individual, or group – that is capable of
acting against an asset in a manner that can result in harm. This can be intentional; i.e., an attacker, but
also unintentional; e.g., a well-intentioned, but inept, computer operator who trashes a daily batch job by
typing the wrong command.
• Threat event: Event with the potential to adversely impact an asset. An attack is a specific type of threat
event that is the result of an intentional malicious activity of an attacker, which is a specific type of threat
agent.
Vulnerability
• The probability that an asset will be unable to resist the actions of a threat agent [3].
• A weakness which allows an attacker to threaten the value of an asset.
Domain
A set of related entities that share one or more characteristics and define the semantic of a specific field. This
concept is essential to the next definition.
Risk Domain
A domain consisting of entities that share one or more characteristics relevant to risk management or
security. A risk domain is also a context or set of conditions that affects a risk exposure level.
Risk Control, Treatment, Mitigation
• An action, device, procedure, or technique that reduces a threat, a vulnerability, or an attack by
eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so
that corrective action can be taken.
• The deployment of a set of security services to protect against a security threat.
Control Requirement
A formalized need to be fulfilled by means of a control in order to face an identified threat.
Asset at Risk
• Anything tangible or intangible that is capable of being owned or controlled to produce value.
• Any data, device, or other component of the environment that supports information-related activities.
Policy
A set of rules which governs the behavior of a system:
24. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 24
• Exists at different levels: Strategy, Management, Design
• May be of different types: Operational, Structural, and Behavioral
Modeling Options
There are three different options for modeling risk and security aspects with the ArchiMate language:
1. The use of ArchiMate 2.1 concepts unmodified, as specified in the standard.
2. The use of the extension mechanisms as specified in the standard to define additional attributes or
specializations of existing ArchiMate concepts.
3. The use of additional concepts that do not yet exist in the ArchiMate 2.1 standard and can be directly
linked to existing concepts.
Of course, it is likely that a combination of these options will be used. If a combination of options 1 and 2
suffices, this would result in what could be called a “risk and security overlay” of the ArchiMate language,
which may or may not be proposed for inclusion in the standard. If it turns out that option 3 is also required,
this will result in proposing an actual risk and security extension for the standard.
Mapping of Consolidated Risk and Security Aspects to the ArchiMate Language
Although the TOGAF and ArchiMate standards, and various other standards and frameworks, deliver very
valuable material that can help practitioners understand risk and security in the EA practice, they do not
include specific guidelines and examples on how to model security and risk management. Therefore, in the
remainder of this White Paper, this content is developed. Specific mappings will be suggested, and actual
ArchiMate concepts and relations will be combined with profiling and specialization. Also, examples from
case materials will be used to illustrate the use of these concepts.
The remainder of this section proposes a mapping between the consolidated risk and security concepts
defined previously and components and concepts from the ArchiMate 2.1 specification.
Loss Event
A loss event can be mapped to the business event concept in ArchiMate, which may be triggered by a threat
event. It may be useful to define a specific specialization of a business event to denote a loss event.
Threat
As indicated before, the term “threat” is ambiguous. The general notion of threat as a threatening
circumstance can be modeled as a driver in the ArchiMate language. The mappings of the more specific
concepts of “threat agent” and ‘threat event’ are given below.
• Threat agent: Different types of threat agent can be modeled as different kinds of active structure
elements in the ArchiMate language; e.g., a business actor, business role, application component, node,
system software, or device.
• Threat event: A threat event may map most naturally to a business event in the ArchiMate language.
Because the concept of threat event plays an important role in risk management, it is advisable to
introduce it as a specialization of a business event.
25. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 25
Risk
A risk is a quantification of a threat, and as such it maps most naturally to an assessment in the ArchiMate
language. Because of the central role of this concept in ERM, the proposal is to define the risk concept as a
specialization of an assessment.
Risk Metrics
As well as the different types of risks (e.g., initial and residual), may be defined as attributes in a risk profile
of an assessment.
Vulnerability
A vulnerability is the result of analyzing the weaknesses of elements in the architecture considering all the
environmental factors that could affect the system. An example of a vulnerability is a non-encrypted
communication channel over the public Internet, which means that confidential messages may be intercepted.
For explicitly modeling a vulnerability, it most naturally maps to an assessment in the ArchiMate language.
In that case, the proposal is to model a vulnerability as a specialization of an assessment. Alternatively, it
may be specified as an attribute of an asset at risk or a risk domain.
Domain
The ArchiMate language does not yet define a general domain concept. The location concept represents a
specific kind of domain (i.e., a geographic domain). The grouping relation can also be used to group elements
that belong to a certain domain, but has some limitations (e.g., it is not possible to link a group to other
elements with a relation). For an example of the use of the domain concept, see Use of the Risk Domain
Concept.
Risk Control, Treatment, and Mitigation
Depending on the kind of control, almost any core concept or combination of core concepts can be used to
model the implementation of the control. A control may also be realized by a grouping of a number of core
concepts, which is something that cannot properly be modeled in the ArchiMate language (see Domain).
Control Requirement
In a risk analysis process, a specification of an action or set of actions that have to be performed or that
should be implemented as part of the control, treatment, and mitigation of a particular risk. A control
requirement is realized by core entities used for mitigation, treatment, and control.
Asset at Risk
Almost any core concept or combination of concepts can be an asset to the organization. A specific asset
profile can be assigned to these concepts to specify specific attributes of assets; e.g., their value.
Alternatively, the concept can be associated with the ArchiMate value concept.
Policy
At the design level, a policy may map to a principle from the ArchiMate Motivation extension. The
ArchiMate language does not yet have the concept of operational policy. This is a candidate concept that
could be considered for a future version of the ArchiMate standard. Note that the concept of policy can be
used in a generic way, with risk policy and security policy as possible specializations.
26. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 26
Figure 14summarizes the main mapping of the concepts.
Figure 14: Mapping of Risk and Security Concepts to the ArchiMate Language
27. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 27
Case Studies and Examples
This section further explores the risk domain concept and uses the ArchiMate 2.1 language together with
additional risk domain notations to depict four scenarios. The first is an original scenario involving security at
aircraft maintenance facilities, and the next three are elaborations of the Coldhard Steel scenario [9]. This
scenario, part of the CAS ERM Overview, describes the risks faced by a US-based manufacturer of steel
products, such as roller and ball bearings, used in industrial machinery. The final scenarios in this section
illustrate a vulnerability assessment of technical infrastructure.
Use of the Risk Domain Concept
In Mapping of Consolidated Risk and Security Aspects to the ArchiMate Language, this White Paper has
defined a risk domain as “consisting of entities that share one or more characteristics relevant to risk
management or security”. Table 1 details these common characteristics and provides examples of domains
that share them. The entries describing common characteristics are numbered for reference in examples later
in the text.
Table 1: Common Characteristics Shared by Entities within a Risk Domain
Common Characteristic Example Risk Domains
Exposure to a threat or risk Registered users of an e-commerce website from which credit card
information has been stolen, and are therefore particularly vulnerable to
fraudulent charges, or residences that do not have smoke alarms, and
are therefore particularly vulnerable to fire.
Possession of a vulnerability Individuals who record their passwords on paper near their computer
workstations, or instances of an operating system that are missing a
critical security patch.
Possession of a control
requirement
Individuals recently released from prison who must report regularly to a
parole officer, or wireless devices that access a corporate network that
transmits sensitive information, and must therefore be authenticated,
authorized, and monitored whenever they are connected.
Participation in a control,
treatment, or mitigation
Individuals who use password managers to generate and store complex,
random passwords for the websites they access, or firewalls that control
access to a government network.
Participation in a threat agent Individuals with criminal records who possess unlicensed handguns or
flammable material stored in a warehouse.
Relevance, authority, or influence
of a control, treatment, or
mitigation
Individuals subject to the laws of a particular jurisdiction, or all
neighborhoods in a city subject to extra police patrols due to high crime
rates.
Inclusion in a classification for the
purpose or assessing or
mitigating risk
All computers that are connected to the same corporate network and
running a particular operating system, for which a patch assessment or
patching cycle could be developed, or all individuals living in a
neighborhood that has been exposed to toxic industrial chemicals, for
which a set of health checks or precautionary recommendations could be
developed.
28. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 28
ArchiMate modelers can use the grouping relationship to identify domains and describe their contents. The
grouping concept is uniquely suited for this purpose, since it is the only relationship within the language in
which any number of elements representing any combination of concepts can participate. This flexibility is
critical to representing domains, since instances, classifications, and assessments of vulnerabilities, risks,
threats, controls, and related risk concepts frequently aggregate diverse elements.
For example, a software component may possess an internal vulnerability that could be exploited by an
attacker, but if the software component is used within a cardkey system to control physical access to an
aircraft maintenance facility operated by an airline, its vulnerability may put the functioning of the aircraft,
the lives of passengers and crew, and the financial health of the airline at risk. A comprehensive approach to
mitigating the overall risk of access control software malfunction could require:
• Technical controls such as software patches and code restructuring instituted by the software vendor
• Administrative controls such as:
o Enhanced quality assurance procedures instituted by the software developer
o Revisions in the contract between the airline and the software vendor
o Audits of the software vendor by the airline or a trusted agent
o Enhanced patching procedures instituted by the airline’s IT organization
• Physical controls such as placing the onsite access control server appliance in a locked closet
In addition, different domains might require different controls to mitigate the risk (Table 1, entry 6). If the
airline uses two aircraft maintenance facilities at different airports with separate instances of the same
cardkey system, but outsources the operations of one to a service provider, then mitigating the risk at the
second facility could also require:
• Administrative controls such as:
o Enhanced patching procedures instituted by the outsourcer’s IT organizations
o Revisions in the contract between the airline and the outsourcer
o Audits of the outsourcer by the airline or a trusted agent
The ArchiMate grouping relationship can be used for this scenario to organize both the elements of risk, and
the measures taken to mitigate risk. However, in order to express the mitigation relationship between the risk
of software attack and different combinations of measures required to mitigate that risk at the two aircraft
maintenance facilities, ArchiMate modelers must be able to combine diverse elements into risk domains that
can participate in explicit mitigation relationships (Table 1, entry 1).
Figure 15 illustrates the use of the ArchiMate 2.1 language, and the opportunities for expression of domains
and mitigation relationships. The diagram expresses domains as ellipses with dashed borders, and mitigation
relationships as thick grey lines with long dashes, and hollow-point arrows pointing from the mitigating
domain to the domain exposed to the risk. The two facility domains share exposures to the same risks (Table
1, entries 4 and 6) which are expressed as drivers. The shared risk of unauthorized access positively
influences the risk of aircraft malfunction, which has enterprise-wide implications. Per the scenario, some
mitigation requirements are specific to one of the two facilities, and some are shared. Each of the three
29. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 29
mitigation domains (Table 1, entry 4) contain requirements that mitigate the risks of software attack and
unauthorized access.
Figure 15: Aircraft Maintenance Scenario with Risk Domains
Figure 18 and Figure 19 illustrate a risk mitigation approach – continuous improvement of machine reliability
– which applies across the entire Coldhard Steel risk domain (Table 1, entry 1). However, the Gary and
Chicago factory risk domain have different vulnerabilities (Table 1, entry 2), and therefore the local
implementation of the enterprise risk mitigation strategy constitutes two very different domains (Table 1,
entry 4).
Coldhard Steel
This section uses the Coldhard Steel company case from reference [9] to illustrate the stereotyping of
ArchiMate Motivation extension concepts as risk concepts. Coldhard Steel manufactures products such as
roller and ball bearings that are used in other industrial machinery. Coldhard Steel operates in the Midwest
30. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 30
region of the United States, is family-owned, and has a unionized labor force. The Coldhard Steel case has
been selected because it is a well-accepted example case in the risk and security field.
Figure 16 illustrates such use of stereotyped ArchiMate 2.1 concepts to model risk and security concepts.
Coldhard steel experiences a threat that machines may fail due to inadequate power supply. This threat is
mapped onto the concept of driver. This threat leads to a risk that once a year the power supply is inadequate,
and with an effect that the production loss is $100.000, an assessment is stereotyped to risk. A control
objective is added to mitigate the risk. The control objective is to increase peak capacity of the power
supplies. The concept goal is stereotyped to control objective. A control measure, replace factory power
supplies, is used to realize the control objective. A requirement is stereotyped to control measure to model
this.
A threat can also lead to a loss event, in the case of Coldhard Steel a power supply failure. A business event
is stereotyped to express this. A vulnerability of an asset can lead to a loss event. In the case of Coldhard
Steel, the power supply cannot handle large power fluctuations. An assessment is stereotyped to express this.
ArchiMate Core elements are stereotyped to assets. In this example the asset realizes the control measure, to
illustrate that the control measure is implemented.
Figure 16: Coldhard Steel, Example 1
Figure 17 illustrates two other examples. The left figure can be read as follows. There is a threat that an
employee submits a compensation claim for work-related injuries. This leads to the risk that the
compensation claims for injuries are unacceptable. A control objective is stated to reduce the exposure to
compensation claims. The control measure is to implement safety procedures. The threat can lead to the loss
event work-related safety incident. This loss event is possible through the vulnerability of inadequate safety
procedures.
The right part of the figure illustrates yet another kind of risk example. Coldhard steel is situated in an area
where there is a threat of tornados. These tornados can cause damage to plant and equipment. This leads to
the risk that there are unacceptable costs to repair the damage. This leads to the control objective to reduce
exposure to tornado damage and the control measure to improve the structural integrity of the building.
31. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 31
The threat can lead to the loss event that the tornado hits the factory. The vulnerability that the equipment is
not resistant to tornados leads to the loss event and the risk.
Figure 17: Coldhard Steel, Examples 2 and 3
As another example of the use of the domain concept, as explained in the previous subsection, Figure 18 and
Figure 19 illustrate a risk mitigation approach – continuous improvement of machine reliability – which
applies across the entire Coldhard Steel risk domain (Table 1, entry 1). However, the Gary (Figure 18) and
Chicago (Figure 19) factory risk domains have different vulnerabilities (Table 1, entry 2), and therefore the
local implementation of the enterprise risk mitigation strategy constitutes two very different domains (Table
1, entry 4).
32. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 32
Figure 18 Mitigation of Machine Failure Risk at Coldhard Steel Gary Factory
33. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 33
Figure 19: Mitigation of Machine Failure Risk at Coldhard Steel Chicago Factory
34. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 34
Vulnerability Assessment of a Technical Infrastructure
A vulnerability assessment is the process of identifying, quantifying, and prioritizing (or ranking) the
vulnerabilities in a computer network or system. A vulnerability assessment may include the use of a
penetration test (pen test); i.e., an attack on a computer network or system with the intention of finding
security weaknesses, potentially gaining access to it, its functionality, and data. This process may be
supported by one of the many available commercial or open source automated vulnerability scanners, which
produce a report of the vulnerabilities found in a computer network, host, or set of hosts.
Figure 20 below shows an example of the results of a vulnerability scan of a single application server. Five
vulnerabilities are found, with varying levels of risk (risk factors), related to different ports. The overall
security of the server is determined by the weakest link; i.e., the maximum of the risk factors of the relevant
vulnerabilities.
Figure 20: Results of a Vulnerability Scan
Figure 21 shows the context of one of these vulnerabilities. The vulnerability is present on three different
hosts in the network. Also, a known control measure that can be used to mitigate the risk associated with
vulnerability is shown in the model.
35. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 35
Figure 21: Vulnerability Context
Although a vulnerability assessment provides an overview of vulnerabilities at the technology level, this is
not sufficient for a well-informed assessment of the risks at the business level. An EA model can help to
analyze the business impact of the technical vulnerabilities, as illustrated in the example in Figure 22. Based
on the results of this analysis, the (intermediate or final) results of which may be captured as profile elements
attached to ArchiMate concepts, a decision can be made as to whether a control measure should be
implemented to mitigate the risk.
36. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 36
Figure 22: Business Impact of a Technical Vulnerability
37. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 37
Summary and Conclusions
ERM and security are closely interlinked with EA, including the design of organizations and the IT
applications and infrastructure that support them. Therefore, this White Paper proposes how ERM and
security can be expressed in the ArchiMate language for EA modeling.
In order to identify the relevant concepts, this White Paper examines a wide variety of standards and
frameworks for ERM and security deployment, including those employed in the risk and security-related
activities of The Open Group. Based on this, the paper establishes a common set of risk and security
concepts, and demonstrates a mapping of these concepts to the ArchiMate language. Example cases illustrate
these concepts.
The mapping and examples show that most of the risk and security concepts can be mapped to existing
concepts in the ArchiMate language (Core and Motivation extension). However, to improve understanding, it
is helpful to make explicit which of the risk or security concepts they represent. Specialization, one of the
language extension mechanisms described in the ArchiMate standard, is primarily used for this. Two
elements used in some of the examples are not in the standard language: the domain concept, a grouping that
can have relationships with other concepts; and the mitigation relationship.
This White Paper also illustrates that the security and risk concepts and relationships can be added to a wide
range of ArchiMate viewpoints. Any of the viewpoints described in the current ArchiMate 2.1 standard can
be overlaid with risk and security concepts, and organizations may adopt these to assess risks. In a similar
way, these concepts can also be used to express risk and security aspects in several TOGAF diagrams. In
addition, modelers may add a number of additional viewpoints; e.g., a risk mitigation domain viewpoint (see
the examples in Use of the Risk Domain Concept) or a risk analysis viewpoint (see the examples in the
Coldhard Steel section).
38. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 38
References
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
[1] R.E. Giachetti: Design of Enterprise Systems, Theory, Architecture, and Methods, CRC Press, Boca
Raton, FL, 2010 (p.4).
[2] ArchiMate®
2.1 Specification, Open Group Standard (C13L), December 2013, published by The Open
Group; available at: www.opengroup.org/bookstore/catalog/c13l.htm.
[3] Risk Taxonomy (O-RT), Version 2.0, Open Group Standard (C13K), October 2013, published by The
Open Group (as part of the Open FAIR Body of Knowledge); available at:
www.opengroup.org/bookstore/catalog/c13k.htm.
[4] Institute of Risk Management: A Risk Management Standard, 2002; refer to:
www.theirm.org/publications/documents/Risk_Management_Standard_030820.pdf.
[5] Oxford English Dictionary; refer to: www.oed.com (consulted December 2013).
[6] D. Ionita: Current Established Risk Assessments Methodologies and Tools, MSc Thesis, University of
Twente, Enschede, the Netherlands, July 2013.
[7] J. Sherwood, A. Clark, D. Lynas: Enterprise Security Architecture: A Business-driven Approach,
CMP Books, 2005.
[8] J. Sherwood, A. Clark, D. Lynas: Enterprise Security Architecture, White Paper, SABSA Institute,
2009.
[9] Committee of Sponsoring Organizations of the Treadway Commission (COSO) Enterprise Risk
Management – Integrated Framework, 2004; refer to:
www.coso.org/documents/coso_erm_executivesummary.pdf.
[10] Casualty Actuary Society (CAS) Overview of Enterprise Risk Management, 2003; refer to:
http://www.casact.org/area/erm/overview.pdf.
[11] Risk Management Handbook for Healthcare Organizations, Sixth Edition, Volume 1, American
Society for Healthcare Risk Management (ASHRM), 2011.
[12] SANS Institute; refer to: www.sans.org/information_security.php (consulted December 2013).
[13] 44 United States Code (USC) 3542 – Definitions; refer to: www.law.cornell.edu/uscode/text/44/3542
(consulted December 2013).
[14] Chad Perrin: The CIA Triad; refer to: www.techrepublic.com/blog/it-security/the-cia-triad/488
(consulted December 2013).
[15] E. Dubois, P. Heymans, N. Mayer, R. Matulevičius: A Systematic Approach to Define the Domain of
Information System Security Risk Management (ISSRM), in Intentional Perspectives on Information
Systems Engineering, S. Nurcan, C. Salinesi, C. Souveyet, J. Ralyté, Eds. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2010 (pp.289–306).
39. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 39
[16] AS/NZS 4360: Risk Management, SAI Global, 2004.
[17] ISO/IEC Guide 73: Risk Management – Vocabulary – Guidelines for Use in Standards, Geneva:
International Organization for Standardization, 2002.
[18] ISO/IEC 13335-1: Information Technology – Security Techniques – Management of Information and
Communications Technology Security – Part 1: Concepts and Models for Information and
Communications Technology Security Management, Geneva: International Organization for
Standardization, 2004.
[19] E. Grandry, C. Feltus, E. Dubois: Conceptual Integration of Enterprise Architecture Management and
Security Risk Management, The Fifth Workshop on Service-Oriented Enterprise Architecture for
Enterprise Engineering (SoEA4EE’2013), Vancouver, BC, Canada.
[20] TOGAF®
Version 9.1, Enterprise Edition, Open Group Standard (G116), December 2011, published
by The Open Group; available at www.opengroup.org/bookstore/catalog/g116.htm.
40. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 40
About the Authors
Iver Band is a practicing Enterprise Architect and a developer and communicator of
Enterprise Architecture standards and methods. Recently, he joined Cambia Health
Solutions, where he shapes solutions that promote accountability, quality, and efficiency
in healthcare delivery. For the previous six years at The Standard, a diversified financial
services company, he focused on business solutions and governance, and prior to that,
infrastructure. He guided contact center and CRM implementations, claims system
modernization, end-user computing, and trading workflow automation. In his
infrastructure role, Iver developed data center, computing platform, and resilience
strategies. Prior to his work at The Standard, Iver had a lengthy career at Hewlett-
Packard with roles ranging from IT Director for a global business to HP Labs Visiting
Technologist. At HP Labs, he researched security topics such as role engineering, and
led the development of a patented approach to network security management.
Iver also serves as Director of Enterprise and Solution Architecture for EA Principals, a
training and consulting firm, for which he works with clients, develops curriculum
materials, and edits the Enterprise Architecture Professional Journal and EAPJ.org. Iver
represents EA Principals in The Open Group, where he is the elected Vice Chair of The
ArchiMate Forum. As Vice Chair, Iver has led development of a number of Open Group
White Papers.
Iver is TOGAF 9 Certfied, ArchiMate 2 Certified, a Certified Information Systems Security
Professional (CISSP), a Certified Information Professional (CIP), and a Prosci Certified
Change Consultant.
Wilco Engelsman is a research consultant at BiZZdesign, specialized in the areas of
enterprise architecture, business requirements management and enterprise risk
management. He was one of the main contributors to the development of the Motivation
extension of the ArchiMate standard. He is also pursuing a PhD in Computer Science at
the University of Twente.
Christophe Feltus graduated as an Electromechanics Engineer from the Institut
Supérieur Industriel des Art et Métiers Pierrard (Belgium) and Doctor of Science
(Computer Science) from the University of Namur (Belgium). He worked for several years
in private companies as: Production Head at Pfizer SA in Jette, Project Coordinator at
Nizet Entreprise in Louvain-la-Neuve, and Assessor for the Civil Belgium Aviation
Administration in Brussels, Belgium. Than he joined the Public Research Centre Henri
Tudor in the Grand-Duchy of Luxembourg in 1999 to work in the field of Service Science
and Innovation. There he has taken part in projects related to IT security, IT governance,
business IT/alignment, and enterprise architecture modeling. In 2015, the Public
Research Centre Gabriel Lippmann and the Public Research Centre Henri Tudor merged
to become the Luxembourg Institute of Science and Technology.
Sonia Gonzalez is a Senior Consultant at Dux Diligens. Sonia provides consulting and
training services in the areas of business innovation, business process modeling, and
Enterprise Architecture. In this position she is involved in the development of new
products and services that the company is offering to its customers in Latin America and
Spain. She is also TOGAF
®
9 Certified and ArchiMate
®
2 Certified, and is a trainer for an
accredited training course provider and has developed workshops and EA consultancy
projects using the TOGAF standard as a reference framework and the ArchiMate
standard as a modeling language. As a representative of an Open Group member
organization, she is participating in several projects in the Architecture and ArchiMate
Forums.
41. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 41
Jim Hietala, CISSP, GSEC, is Vice President, Security for The Open Group, where he
manages all security and risk management programs and standards activities, including
the Security Forum. He has participated in the development of several industry standards
including O-ISM3, O-ESA, Risk Taxonomy, and O-ACEML. He also led the development
of compliance and audit guidance for the Cloud Security Alliance v2 publication.
Jim is a frequent speaker at industry conferences. He has participated in the SANS
Analyst/Expert program, having written several research white papers and participated in
several webcasts for SANS. He has also published numerous articles on information
security, risk management, and compliance topics in publications including CSO, The
ISSA Journal, Bank Accounting & Finance, Risk Factor, SC Magazine, and others.
An IT security industry veteran, he has held leadership roles at several IT security
vendors. Jim holds a BS in Marketing from Southern Illinois University.
Henk Jonkers is a senior research consultant, involved in BiZZdesign's innovations in
the areas of Enterprise Architecture and engineering. He participates in multi-party
research projects, contributes to training courses, and performs consultancy
assignments. Previously, as a member of scientific staff at an applied IT research
institute, he was involved in research projects on business process modeling and
analysis, EA, SOA, and model-driven development. He was one of the main developers
of the ArchiMate language and an author of the ArchiMate 1.0 and 2.0 Specifications,
and is actively involved in the activities of The Open Group ArchiMate Forum.
Sébastien Massart is a senior consultant at Arismore and is responsible for the first
ArchiMate training center in France. He manages the ArchiMate Work Group at The
Open Group France, providing methodology and assessing competencies to elect new
trainers. He works across a variety of sectors, with a particular focus on
Telecommunications and Industries. His current mission is a project which bridges the
gap between business and IS/IT through the Entreprise Architecture Taskforce. Prior to
his current role, he was a Technical Architect on a range of complex infrastructures.
42. Modeling Enterprise Risk Management and Security with the ArchiMate®
Language
www.opengroup.org A White Paper Published by The Open Group 42
About The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through IT
standards. With more than 400 member organizations, The Open Group has a diverse membership that spans
all sectors of the IT community – customers, systems and solutions suppliers, tool vendors, integrators, and
consultants, as well as academics and researchers – to:
• Capture, understand, and address current and emerging requirements, and establish policies and share
best practices
• Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source
technologies
• Offer a comprehensive set of services to enhance the operational efficiency of consortia
• Operate the industry’s premier certification service
Further information on The Open Group is available at www.opengroup.org.