Security Architecture
Security architecture is the process of designing and oversee the implementation of security controls within an organization's IT infrastructure to protect IT assets for harmful actions such as unauthorized access modification or deletion, data disclosure...
β‘οΈ Security Architecture is Enterprise Architecture applied to IT.
Security architects are responsible for identify the organization needs, and designing the appropriate security controls that are tailored with the organization strategy, goals, and objectives β .
They will identify risks and plan security controls to reduce or mitigate them under an acceptable level, all by focusing on what the company need, so all risks may not be mitigated/handled.
π― This is a continuous process, controls must be continually reviewed and updated to ensure that they are effective and appropriate.
Frameworks like SABSA, TOGAF, or OSA are methodologies to implement security architecture.
Additionally, some security controls may be enforced:
- Regulations according to the activity (ex: PCI DSS or HIPAA)
- Guidelines or industry standards
- ISO
- NIST, NSA
- CIS Security
- SANS (see: critical security controls...)
- Providers (ex: Cisco...)
For a good laugh, see some excuses to not do your job properly.
Mindset
It's important that before thinking about "security" or what makes something "secure", a security architect must think what values it has for the company.
This is done by identifying risks, prioritizing them, and evaluating their impact along the cost to mitigate them under an acceptable level of risk. Based on these, the security architect will implement more or less security controls as long as "it is worth it".
- The losses are significant
- The losses are not lower than the cost to set up controls
π You should view security as a way to enable business, and not preventing it.
π Security give a competitive value to product. For instance, by providing a secure way for customers to do purchases on their smartphone, they can increase its value on the market.
π Security is essential for cooperation between business. For instance, a company must trust another company that the data they share with them is properly secured/managed.
π§βπ³ Geoff Rob's rules for a successful solution architect are a good reference for security architects:
- Listen: understand the problem before trying to solve it
- Design Acceptance: design for people, not for computers
- Recognize and challenge assumptions: don't stay idle, learn...
- Communicate effectively: let people express themselves...
- Simplify complex ideas: not the best, but the best fit for the client
- Be flexible and adaptable: Keep an open mind...
- Focus on the big picture: costs, impacts, benefits, priorities...
- Leverage client's investment: use the infrastructure in place...
- Measure twice, cut once: use scalable/replicable solutions...
- Market Awareness: global view of alternative solutions, trends...
Security controls
Security controls are security measures to reduce/prevent risks.
π Examples: Firewalls, IDS/IPS, Access control, Updates management, Logging and monitoring, Awareness training, Background checks, Two-factor authentication, Physical security controls...
π There are 3 types of controls: Preventive, Detective, and Corrective.
The security architect need to have a broad view of the organization as they will interact with everyone, not only the IT service. They will have to understand the security needs of the organization, and create principles, policies, guidelines, and standards to design and implement the necessary security controls.
Security controls can be technical or administrative, physical or digital, and should include the cloud and IoT devices.
βοΈ Following a checklist is unlikely to meet the business needs or provide real benefits. A security architect mustn't only rely on it, as they need to more sophisticated approach balancing the needs and requirements, risks, and technologies with the security. β Solutions should be selected according to the needs/goals of the organization.
β‘οΈ See the COBIT framework.
β‘οΈ A security control system is important to ensure security controls are effective, and to improve them. They employs a feedback loop with three sub-systems: control (ex: monitoring, detect issues), measurement (mesure performance, analyze impacts), and decision (ex: determine a course of action).
Model for business architecture
A company architecture is made up of smaller sub-architectures. By following this model, it ensures that security architects find both risks and security controls for each level.
For instance, one sub-architecture may have access-control, another recovery plans...
This a pyramid where the top is supported by lower level architectures, and higher level are developed in architectures levels below.
It important that everyone involved in security architecture understand each layer to ensure that security controls are properly implemented.
1. Business Architecture: define how the business is structured (processes, functions, strategies, policies...).
π Identify Business requirements and Business drivers...
2. Information Architecture: define how information and data is designed and organized (databases, data sources...).
π See Data governance to efficiently exploit/manage/protect data...
3. Applications Architecture: define the design and organization of applications (interfaces, interactions, ecosystems...).
π Identify required access control, secure coding practices...
4. Infrastructure Architecture: define the physical and logical resources (hardware, software, network, storage, cloud...).
π Identify required security elements to secure resources
Systems approach to security architecture
A systems approach is a structured way to think about the security of a system, as they are becoming more complex (cloud...). It ensures that:
- every aspect is considered to bring the most benefits
- that decisions are rational, goals are met
- systems are efficiently exploiting the company environment
We break down the system using a top-down approach, into less complex sub-systems and components. Each is seen as a black-box in which we only know the I/O. Using "logical flow analysis", we analyze and ensure that all aspects of the system are considered.
π You must understand the scope/perimeter/context and consider all aspects of the system (ex: external services...).
π Everything (ideas, needs, decisions) is documented. Decisions should be rational and traceable (ex: use peer review...). You could use a scoring system to evaluate options and explain the selection of one.
π Start from business needs to design the system. Take into account the environment (see PESTEL, SWOT matrix).
π We must be able to tell how the system perform, to ensure its efficiently used (metrics; KPI; control, measurement, and decision).
Security Program
A security program must be public, realist, simple, accurate, and adapted to the business of the company.
Setting up a program show the intention of the company to comply with legal regulations.
- βοΈ If not followed, it will be used to punish the company
- π« It must be supported by the executives
- βͺ It must be taken in consideration in every decision
- πΈ It must be proactively applied (formations...)
- π€ It's important to document the security program
These are usually based on industry best practices and standards.
- ISO 27001
- SP 800-53
π¨οΈ Policies (based on legal requirements and business principles) π¨οΈ
- Corporate security policy: the company approach/strategy to security, in accordance to the business objectives
- Specific security policies: based on the corporate security policy, more detailed (ex: emails, incidents...)
β‘οΈ Objectives, principles, scope, obligations and sanctions...
βοΈ Directives/Standards βοΈ
- Security element directives: define how security controls are implemented and maintained based on policies
β‘οΈ Objectives, principles, scope, obligations and sanctions...
π Guides/Guidelines π
- Security guidelines: advices and best practices to apply directives/policies, based on directives and policies
π§ Procedures/Controls π§
- Security procedures: instructions to perform security-related tasks based on guides and directives
Roles and responsibilities
For a program to be successful, it's important to define roles and responsibilities of each stakeholder, so that they are aware of what they should do to make the security program successful.
- Responsible (owner) π: approve, enforce, modify, revoke
- Participate (has an expertise) π’: draft, contribute, review
- Is consulted (has an understanding) βοΈ: feedback, implementation
- Is informed (has to comply) π¦: they are contributing to the document, but they need to know about it to do their work
β‘οΈ Usually, each role is responsible for ensuring that their area of responsibility is addressed in policies, procedures, and guidelines.
For instance,
- Executives (role) could be "responsible of the policies" (responsibility)
- The CISO (role) could be "participates in policies" and "responsible of directives/guidelines/procedures" (responsibility)
- ...
π This is usually a matrix of roles by documents (policies, directives, guidelines, procedures). In each cells, there is the type of responsibility.
π» To-do π»
Stuff that I found, but never read/used yet.
Documents/Metrics
- BCP (Business continuity Plan)
- DRP (Disaster Recovery Plan?)
- SLAs (Service Level Agreement)
- SLOs (Service Level Objectives)
- SLIs (Server Level Indicators)
- RTO (Recovery Time Objective): max interruption duration allowed
- RPO (Recovery Point Objective): max data loss duration allowed (1 hour lost?)
- BIA (Business Impact Analysis)
- DCP (how much downtime allowed?): 99%/... uptime (maintenance in? we must check. sometimes, we can balance update to not have any downtimes)