Security Architecture and design

Security architecture is a set of security principles, methods and models designed to align to
organisation objectives and help keep the organization safe from cyber threats. Security
architecture translates the business requirements to executable security requirements. .
The security infrastructure itself refers to the systems, processes, and tools already in place to
prevent or mitigate any damage from data breaches or other attacks on IT systems. The
infrastructure refers to t he supporting elements needed for functionality, and the architecture
refers to the cohesive design of the elem ents.
Security design refers to the techniques and methods that position those hardware and software
elements to facilitate security. Items like handshaking and authentication can be parts of network
security design.

A good security architecture is a combination of three components, namely:

  Tools
 Processes
 People
Security Architect duties and responsibilities of the job
In addition to anticipating possible security threats and identifying areas of weakness in a
network system, a Security Architect must respond promptly and effectively to possible breaches
of security. A Security Architect job description generally includes:
 Reviewing current system security measures and recommending and implementing
enhancements
 Conducting regular system tests and ensuring continuous monitoring of network security
 Developing project timelines for ongoing system upgrades
 Ensuring all personnel have access to the IT system limited by need and role
 Establishing disaster recovery procedures and conducting breach of security drills
 Promptly responding to all security incidents and providing thorough post-event analysis
Key Elements
A typical security architecture is quite long as it tackles the following areas:
 Security protocols: A security architecture defines in detail the tools and processes used
in threat detection and prevention, as well as those used in incident response (the set of
instructions that guides IT professionals in dealing with security breaches) and disaster
recovery (a detailed plan that allows business processes to resume or continue despite a
security incident). For instance, the security architecture might include specific
requirements that security software vendors need to fulfill to win a bid. Incident response
refers to
 Account creation and management: The security architecture also includes a guide
detailing user account creation, what access to grant to the particular user, and what
restrictions to impose. A security architecture must protect the whole IT infrastructure.
As such, it should detail who can access sensitive data and who cannot. An accounting
staff in charge of payroll processing, for example, should have access to employee
timesheets and the payroll management software. Another accounting staff who handles
the company’s taxes don’t necessarily need the same access. Limiting access to tools that
contain sensitive data effectively reduces risks.
  Security roles and their responsibilities: Vital to any security architecture are the
people who carry out every step within it. Who is responsible for the day-to-day
operations of the security system? Who is in charge of maintaining specific applications
and the whole network? Who are the end-users? Who will be the auditor of the overall
security architecture? The answers to these questions should be part of the security
architecture.

 Auditing the security architecture: The IT security landscape is continually changing,

so there is a need to assess an organization’s security architecture regularly. The auditors
must make sure that the current architecture is still in line with the business goals and, at
the same time, meets its needs. After the assessment, they should make the necessary
adjustments to the security architecture.

In all of the areas listed above, the security architecture must contain a detailed, step-by-step
guide on how to carry out each task. Training could even be part of the security architecture,
especially when there are adjustments after an audit.
Benefits of Using the Security Architecture
Some of the benefits are mentioned below.

 Help to protect the important company assets from the outside and provide security to the
important resources to the organization. The architecture provides the limited access to
the user so that the confidential data can be kept secure and safe.
 The architecture defines the common policies and standards that can be used by the every
employee of the company and also define common rules so that no one face any
difficulty to use the system. It helps the organization to reach their goal and easily
conduct their business operations smoothly.
 The other benefit is risk management activities covered by the architecture as the risk
management activity requires continuous assistance and also need continuous
improvement, the security architecture act as a better solution for them.

Challenges in creating an SA
Development of an optimal SA strategy can be difficult, especially when the following common
factors are in play:
 Lack of communication and coordination among various departments or teams when it
comes to managing risks and maintaining IT security
 Failure to clearly articulate the goals of the SA
 Lack of understanding among users and stakeholders about the need to prioritize
information security
 Difficulty calculating the cost and ROI of data protection software tools
 Lack of funding to properly address security issues
 Dissatisfaction with earlier security measures that were developed, such as spam filtering
that flags valid and critical correspondence
 Earlier failures to meet regulatory requirements or business objectives,
 Concerns about the ineffectiveness of earlier IT security investments
Phases of the Security Architecture Process
The four main phases of constructing a security architecture are as follows:
Risk Assessment
During the initial phase, the architect evaluates the business influence of vital assets, the
potential odds of an attack, and the effects of vulnerabilities and security threats. Risk
assessments provide a comprehensive overview of the current state of your enterprise’s
cybersecurity posture; you don’t know where to go if you don’t know where you’re starting!
Design
Following the risk assessment phase, the design and architecture of security services, which
facilitate business risk exposure objectives are developed by the architect. This is essentially the
roadmap for how to handle or fortify your business’s cybersecurity infrastructure and what
measures need to be taken for enhanced protection.
Implementation
Upon creating an overall plan, this next phase deals with putting steps into action. Security
services and processes are implemented, operated, and controlled; assurance services are
designed to ensure that the security policy and standards, security architecture decisions, and risk
management are mirrored in the real runtime implementation.
Operations & Monitoring 
This final phase encompasses the subsequent day-to-day processes, such as threat and
vulnerability management and threat management. Here, measures are taken to supervise and
handle the operational state in addition to the depth and breadth of the system’s security. This
conclud
ing phase is just as important as the previous three and ensures continuous security measures are
in place and appropriately monitored
Security Architecture Framework
Security architecture framework is a consistent set of principles and guidelines for implementing
security architecture at different levels of the business. There are many international framework
standards, each solving a different problem.
Sherwood Applied Business Security Architecture (SABSA)
SABSA (Sherwood Applied Business Security Architecture) is a model and methodology for
developing a risk-driven enterprise information security architecture and service management, to
support critical business processes. It was developed independently from the Zachman
Framework, but has a similar structure. The primary characteristic of the SABSA model is that
everything must be derived from an analysis of the business requirements for security, especially
those in which security has an enabling function through which new business opportunities can
be developed and exploited.
The process analyzes the business requirements at the outset, and creates a chain of traceability
through the strategy and concept, design, implementation, and ongoing ‘manage and measure’
phases of the lifecycle to ensure that the business mandate is preserved. Framework tools created
from practical experience further support the whole methodology.
The model is layered, with the top layer being the business requirements definition stage. At
each lower layer a new level of abstraction and detail is developed, going through the definition
of the conceptual architecture, logical services architecture, physical infrastructure architecture
and finally at the lowest layer, the selection of technologies and products (component
architecture).
The SABSA model itself is generic and can be the starting point for any organization, but by
going through the process of analysis and decision-making implied by its structure, it becomes
specific to the enterprise, and is finally highly customized to a unique business model. It
becomes in reality the enterprise security architecture, and it is central to the success of a
strategic program of information security management within the organization.
SABSA is a particular example of a methodology that can be used both for IT (information
technology) and OT (operational technology) environments.
SABSA matrix
Assets Motivation Process Location
People (Who) Time (When)
(What) (Why) (How) (Where)
Business
Business risk Business organization Business Business time
Contextual The business
model process model and geography dependencies
relationships
Security Security entity
Business Security-
Control strategies and model and Security
Conceptual attributes related lifetime
objectives architectural trust domain model
profile and deadlines
layering framework
Security
Business Entity schema Security
Security Security domain
Logical information and privilege processing
policies services definitions and
model profiles cycle
associations
Users,
Security rules, Platform and Control
Business data Security applications
Physical practices and network structure
model mechanisms and user
procedures infrastructure execution
interface
Identities, Processes,
Security Security step
Detailed data Security functions, nodes,
Component products and timing and
structures standards actions and addresses and
tools sequencing
ACLs protocols
Security Application
Assurance of Operational Security of Security
service and user
Operational operational risk sites and operations
management management
continuity management platforms schedule
and support and support
  

COBIT

COBIT (Control Objectives for Information and Related Technology) helps organisations meet
business challenges in regulatory compliance, risk management and aligning IT strategy with
organisational goals. COBIT 5, the latest iteration of the framework, was released in 2012.
COBIT consists of four main components namely, plan and organize, acquire and implement,
deliver and support, and finally monitor and evaluate

COBIT 5 principles

COBIT 5 is based on five principles that are essential for the effective management and
governance of enterprise IT:

 Principle 1: Meeting stakeholder needs

 Principle 2: Covering the enterprise end to end
 Principle 3: Applying a single integrated framework
 Principle 4: Enabling a holistic approach
 Principle 5: Separating governance from management

These five principles enable an organisation to build a holistic framework for the governance and
management of IT that is built on seven ‘enablers’:

1. People, policies and frameworks

2. Processes
3. Organisational structures
4. Culture, ethics and behaviour
5. Information
6. Services, infrastructure and applications
7. People, skills and competencies

Together, the principles and enablers allow an organisation to align its IT investments with its
objectives to realise the value of those investments.
Benefits of COBIT

The COBIT 5 framework can help organisations of all sizes:

 Improve and maintain high-quality information to support business decisions.

 Use IT effectively to achieve business goals.
 Use technology to promote operational excellence.
 Ensure IT risk is managed effectively.
 Ensure organisations realise the value of their investments in IT; and
 Achieve compliance with laws, regulations and contractual agreements.
By using a combination of the SABSA frameworks and COBIT principles, enablers and
processes, a top-down architecture can be defined for every category in figure 2. As an example,
when developing computer network architecture, a top-down approach from contextual to
component layers can be defined using those principles and processes (figure 4).
 TOG
AF is a framework and a set of supporting tools for developing an enterprise architecture. The
TOGAF architecture development cycle is great to use for any enterprise that is starting to create
an enterprise security architecture. Similar to other frameworks, TOGAF starts with the business
view and layer, followed by technology and information
TOGAF is a useful framework for defining the architecture, goals and vision; completing a gap
analysis; and monitoring the process.
By using SABSA, COBIT and TOGAF together, a security architecture can be defined that is
aligned with business needs and addresses all the stakeholder requirements. After the
architecture and the goals are defined, the TOGAF framework can be used to create the projects
and steps, and monitor the implementation of the security architecture to get it to where it should
be.
WHAT ARE SECURITY ARCHITECTURE'S KEY DELIVERABLES?
So, from a deliverables standpoint, what do you actually get out of security architecture? Again,
it depends on the architect, the business, the frameworks in use, and a host of other variables.
Ultimately, the deliverables you receive will be based on your objectives.
Looking at frameworks specifically, each model is used in different stages of security
architecture - therefore, one framework will never cover everything. However, below we have
compiled a list of some of the more common deliverables that can come from using different
frameworks:
TOGAF EXAMPLES:
Definition of business principles, goals and drivers.
Security architecture roadmaps - or in other words, a list of individual work packages that will
define the target security architecture and show progression from the as-is state to the desired
state within agreed timelines.
Security architecture building blocks. A building block is a package of functionality designed
to meet the business needs across an organization.
Specification of security architecture requirements. This provides a quantitative view of the
solution, stating measurable criteria that must be met during implementation.
SABSA EXAMPLES:
The business attribute model - the heart of SABSA. The business attribute model is an
abstraction of real-life business requirements, detailing definitions and guidelines for a variety of
important business attributes.
A defined security strategy, mapped to control objectives and business attribute profile.
Security policy architecture, which covers security and domain policies that an organization
should follow, complied to the latest security standards and regulatory bodies.
Defined security services. These should be based on security policies, business strategies and
control objectives.
OSA EXAMPLES:
Functionality and technical security controls. These provide a definition of technical security
controls such as access controls, system hardening, security scans, etc.
Software and data integrity protection, a taxonomy of software integrity protection techniques
With a service such as ours here at dig8ital, we would bring deliverables from each of the
frameworks together based on your needs to ensure you receive a fit-for-purpose outcome
throughout all stages of security architecture.
Security Design Principles
Security by design is an approach to software and hardware development that seeks to make
systems as free of vulnerabilities and impervious to attack as possible through such measures as
continuous testing, authentication safeguards and adherence to best programming practices
principle is fundamental truith or proposition serving as the foundation belief or action.
Principle is a declarative statement made with the intention of guiding security design
decisions in order to meet the goals of a system.
1. Economy of Mechanism
This fundamental security principle defines that the security measures implemented in the
software and the hardware must be simple and small. This would ease the testers to test the
security measures thoroughly. If the designed security mechanism is complex then it is likely
that the tester would get a chance to exploit the weakness in the design. So more the design is
simple less are the opportunities for the tester to discover the flaws and more the complex is the
design more are the chances to exploit flaws in the design. When the security design is simple, it
easy to update or modify the design. But when it comes to practice, we cannot consider the
economy of a mechanism as the best security design principle. Because there is a continuous
demand for adding the security features in both hardware, as well as software. Adding security
features constantly makes the security design complex. What we can do to obey this principle
while designing security mechanism is to eliminate the less important complex feature.
2. Fail-safe Defaults
This principle says that if any user wants access to any mechanism then whether the access is
permitted or denied should be based on authorization rather than elimination. By default, all the
mechanism should have a lack of access and the function of a security mechanism is to identify
the condition where the access to the security mechanism should be permitted. This means by
default access to all mechanism should be denied, unless any privilege attribute is provided. This
principle denies unauthorized access. If there occurs any mistake while designing the security
mechanism which grants access based on permission or authorization. That mechanism fails by
simply denying access, which is the safest condition. If there occurs any mistake while designing
the security mechanism which grants access based on exclusion. That mechanism fails by simply
granting access which can not be considered as the safest situation.
3. Complete Mediation
Some systems are designed to operate continuously such systems remember access decision. So,
there must be an access control mechanism which would check every access occurring on the
system. This principle says that the system should not trust the access decisions it recovers from
the system cache. This particular security design principle says that there must be a mechanism
in the system that checks each access through the access control mechanism. However, this is an
exhaustive approach and is rarely considered while designing a security mechanism.
4. Open Design
This security principle suggests that the security mechanism design should be open to the public.
Like in the cryptographic algorithm, the encryption key is kept secret while the encryption
algorithm is opened for a public investigation. This principle is followed by the NIST (National
Institute of Standards and Technology) to standardize the algorithms because it helps in
worldwide adoption of NIST approved algorithms.
5. Separation of Privilege
This security principle states that whenever a user tries to gain access to a system, the access
should not be granted based on a single attribute or condition.
Instead, there must be multiple situations or conditions or attribute which should be verified to
grant access to the system. We also term this as a multifactor user authentication as this principle
says that multiple techniques must be implemented to authenticate a user. For example, while
conducting online money transfer we require user-id, password, transaction password along with
OTP.
6. Least Privilege
The least privilege security design principle states that each user should be able to access the
system with the least privilege. Only those limited privileges should be assigned to the user
which are essential to perform the desired task.
An example of considering and implementing this principle is role-based access control. The
role-based designed security mechanism should discover and describe various roles of the users
or processes. Now, the least set of privileges should be assigned to each role which is essential to
perform its functions. So, the access control mechanism enables each role only those privileges
for which it is authorized. The least set of privileges assigned to each role describes the resources
available each role can access. In this way, unauthentic roles are unable to access the protected
resources. Like, the users accessing database has privilege only to retrieve the data they are not
authorized to modify the data.
7. Least Common Mechanism
Following the least common mechanism, a security design principle there should be minimum
common functions to share between the different user. This principle reduces the count of
communication paths and therefore further reduces the hardware and software implementation.
Ultimately this principle reduces the threat of unwanted access to the system as it becomes easy
to verify if there are some unwanted access to the shared function.
8. Psychological Acceptability
This security design principle says that the security mechanisms design to protect the system
should not interfere with the working of the user every now and then.
As this would irritate the user ad user may disable this security mechanism on the system.
Therefore, it is suggested that the security mechanism should introduce minimum hurdles to the
user of the system.
The security mechanism should not be designed such that it becomes difficult for the user to
access the resources in the system.
9. Isolation
This security design principle is considered in three circumstances. The first condition, the
system that has critical data, processes or resources must be isolated such that it restricts public
access. It can be done in two ways. The system with critical resources can be isolated in two
ways physical and logical isolation. The physical isolation is one where the system with critical
information is isolated from the system with public access information. In logical isolation, the
security services layers are established between the public system and the critical systems.
The second isolation condition is that the files or data of one user must be kept isolated with the
files or data of another user. Nowadays the new operating system has this functionality. Each
user operating the system have an isolated memory space, process space, file space along with
the mechanism to prevent unwanted access. And the third isolation condition is where the
security mechanism must be isolated from such that they are prevented from unwanted access.
10. Encapsulation
This security design principle is a form of isolation which is designed on the principle of object-
oriented principles. Here the processes of the protected system can only access the data object of
the system and these processes can only be invoked from a domain entry point.
11. Modularity
This security designing principle says that the security mechanism must be generated as separate
and protected modules and the security mechanism must be generated using the modular
architecture. This principle helps in updating the security mechanism independently without
modifying the entire system.
12. Layering
Multiple security layers must be used in order to protect the opponent from accessing crucial
information. Applying multiple security layers provides multiple barriers to the adversary if he
tries to access the protected system.
13. Least Astonishment
This security design principle states that the user interface of the system must not amaze the user
while accessing the secure system. He should be able to understand how the security mechanism
is essential to protect the system.
INDIVIDUAL ASSIGNMENT

PThinks of how MUST is integrating IT and its core business process. Using the knowledge you
have learned in risk management, security models, security protocols, security policy and
auditing, enterprise information architecture and security architecture frameworks, design a
enterprise security architeture for MUST based on COBIT .
rivacy Policy