Security Architecture and engineering 

WHAT IS SECURITY ARCHITECTURE?

While security architecture has many definitions, ultimately it is a set of security principles, methods and models designed to align to your objectives and help keep your organization safe from cyber threats. Security architecture translates the business requirements to executable security requirements. 

Frameworks

Much like property architects have guidelines to work within, so too do security architects. These are commonly referred to as 'frameworks'.

What is a security architecture framework? It can be a few different things, but is generally considered 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.

Some companies will also devise their own frameworks. For example, at dig8ital we use best-practices based on three of the world's most common security architecture frameworks: SABSA, TOGAF and OSA (see below). By combining standards, we are able to provide a more versatile service that uses the best guidance from each. This enables us to design, implement and measure highly tailored security requirements and solutions. 

Examples of common security architecture frameworks

1. TOGAF: The Open Group Architecture Framework, or TOGAF, helps determine what problems a business wants to solve with security architecture. It focuses on the preliminary phases of security architecture, an organization's scope and goal, setting out the problems a business intends to solve with this process. However, it does not give specific guidance on how to address security issues.

2. SABSA: Sherwood Applied Business Security Architecture, or SABSA, is a quite policy driven framework that helps define key questions that must be answered by security architecture: who, what, when and why. Its aim is to ensure that security services are designed, delivered and supported as an integral part of the enterprise's IT management. However, while often described as a 'security architecture method', it does not go into specifics regarding technical implementation.

3. OSA: Open Security Architecture, or OSA, is a framework related to functionality and technical security controls. It offers a comprehensive overview of key security issues, principles, components and concepts underlying architectural decisions that are involved when designing effective security architectures. That said, it can typically only be used once the security architecture is already designed.        

WHAT IS THE BENEFIT OF SECURITY ARCHITECTURE?

1. STRONG SECURITY ARCHITECTURE LEADS TO FEWER SECURITY BREACHES

Modern businesses need to have a robust security architecture framework for protecting their most important information assets. By strengthening your security architecture to close common weaknesses, you can drastically reduce the risk of an attacker succeeding in breaching your systems.

One of the top benefits of security architecture is its ability to translate each organization's unique requirements into executable strategies to develop a risk-free environment up and down the business, aligned with business needs and the latest security standards.

As an added benefit, with these measures in place organizations can demonstrate their trustworthiness to potential partners, potentially helping them put their business ahead of competitors.

This will ultimately deliver an architecture that is of long-term benefit to the organization.

2. PROACTIVE SECURITY MEASURES SAVE MONEY

Detecting and fixing security vulnerabilities costs real money. It halts production, requires a thorough investigation and can lead to damaging product recalls or embarrassing press conferences.

In this way, the later in the product development cycle an error is detected, the more money it can cost - not to mention the risk of reputational harm.  

To put that in figures, detecting an error during the coding phase of development could increase the cost of fixing it up to 500% - detecting the same error later, in the production or post-release phases, can cost up to 3,000% more.  

Integrating security throughout each level of product development can reduce the chance that an error slips through. Products are developed with a security context from the ideation phase, and newly developed tools and processes (installed as a part of the security architecture process) help reduce the risk of error at each subsequent stage.

3. IT MAY HELP MITIGATE DISCIPLINARY MEASURES IN THE EVENT OF A BREACH

While legislation differs around the globe as to the consequences for a cyber security breach, one of the common elements is that the more a business tries to reduce its risk and prevent vulnerabilities, the more favorable the outcome may be in the event of an attack. In general, regulators have shown that they respect when organizations do their best and punish businesses that only pretend to try, or do not try at all.

Another important point is that regulations are only getting stricter. Before 2016, nobody had heard of the GDPR and certainly didn't have to adhere to its standards. Now, of course, it guides much of the digital landscape in Europe and the globe. The legislative landscape is working hard to catch up to technology, and for businesses this means that there will likely be more, tighter rules to follow in future.

Creating a strong security architecture, integrating security into the development cycle, using tools and processes to detect errors - these are all vital steps in an organization's efforts to show that it is trying its hardest to defend itself against cyber threats and comply with all relevant regulations to the best of its ability.

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

Example for Fintech walkthrough :

Security architecture and engineering in the context of fintech involve designing and building secure financial technology systems and applications. Given the sensitive nature of financial data and the regulatory requirements in the fintech industry, security is paramount. Here's an overview with examples specific to fintech:

Security Architecture for Fintech:

• Data Encryption:

  • Example: Implement end-to-end encryption for financial transactions, ensuring that data is protected both in transit and at rest. Use strong encryption algorithms like AES-256.

• Secure Access Control:

  • Example: Implement role-based access control (RBAC) to restrict access to financial systems and data. For instance, customer support personnel should have limited access compared to financial analysts.

• Multi-Factor Authentication (MFA):

  • Example: Require MFA for accessing sensitive fintech platforms or performing high-value transactions. This adds an extra layer of security beyond passwords.

• Secure APIs:

  • Example: Ensure that APIs used to connect with external financial institutions (e.g., banks, payment processors) are secured with strong authentication and access controls.

• Data Classification:

  • Example: Classify financial data into categories like public, private, and confidential. Apply access controls and encryption based on data sensitivity.

• Cloud Security:

  • Example: If using cloud services, configure cloud security groups and network security policies to restrict access to fintech applications and data.

• Secure Communication:

  • Example: Use Transport Layer Security (TLS) for securing communication between users' devices and your fintech platform, ensuring data privacy and integrity.

• Blockchain Security (if applicable):

  • Example: If your fintech uses blockchain technology, implement smart contract security audits and consensus algorithm best practices to prevent vulnerabilities like reentrancy attacks.

Security Engineering for Fintech:

• Secure Coding Practices:

  • Example: Train developers to follow secure coding practices to prevent vulnerabilities such as injection attacks (e.g., SQL injection) in fintech applications.

• Secure Mobile App Development:

  • Example: In the case of mobile fintech apps, ensure that data stored on devices is encrypted and that apps are designed to resist reverse engineering and tampering.

• Payment Card Security (if applicable):

  • Example: If your fintech handles credit card data, adhere to Payment Card Industry Data Security Standard (PCI DSS) requirements for secure handling, storage, and transmission of cardholder data.

• Secure DevOps:

  • Example: Integrate security into the DevOps pipeline with automated security testing, including static application security testing (SAST) and dynamic application security testing (DAST).

• Container Security (if applicable):

  • Example: If using containerization (e.g., Docker), ensure container images are scanned for vulnerabilities and follow container security best practices.

• Secure Data Storage:

  • Example: Encrypt sensitive customer data stored in databases and use secure database configurations to protect against data breaches.

• Incident Response Plan:

  • Example: Develop an incident response plan that outlines how to detect, report, and respond to security incidents, including data breaches or unauthorized access.

• Vendor Security Assessment:

  • Example: When partnering with third-party vendors or fintech service providers, conduct thorough security assessments to ensure they adhere to your security standards.

• Compliance Management:

  • Example: Continuously monitor and ensure compliance with relevant financial regulations, such as Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements.

• User Training and Awareness:

  • Example: Train employees to recognize phishing attempts and social engineering tactics, which are often used to target financial institutions.

In fintech, security is not just a technology issue; it's a fundamental part of the business model. Implementing robust security architecture and engineering practices helps protect both your customers' assets and your organization's reputation.