Posts

How-To create Security User Stories

/in

In the previous article, we explored how Scrum enables teams to add security to the backlog and prioritize it based on risk.

Incorporating security into the SDLC ensures that security is not an afterthought but an integral part of the development process.

Security User Stories are specific, actionable items that articulate the security needs of the software in the same way functional requirements are handled.

Writing Security User Stories complements this process by providing clear, actionable security requirements that can be integrated into each sprint.

By treating security stories with the same importance as functional stories, developers can ensure that the software they build is not only feature-complete but also secure.

 

What are Security User Stories?

Security User Stories are descriptions of security requirements written from the perspective of the user or the system. They focus on specific security needs, ensuring that the software not only meets functional requirements but also protects against potential vulnerabilities. Just like traditional user stories that describe a feature or function, security stories express how the system should behave securely.

A typical Security User Story follows the same format as a regular user story:

  • As a [role], I want [goal], so that [benefit].

For example, a Security User Story for web development might look like this:

  • “As a user, I want my session to expire after 15 minutes of inactivity, so that my account is protected from unauthorized access.”

Why are Security User Stories Needed?

Security is often treated as an afterthought, addressed late in the development process or after an incident occurs. This reactive approach leads to vulnerabilities, increased technical debt, and costly security fixes post-release. Security User Stories shift this paradigm by making security an integral part of the development process from the outset. They are necessary for several reasons:

  1. Proactive Security Integration: By incorporating security needs into the backlog from the start, you ensure that security considerations are addressed in each sprint, reducing the risk of vulnerabilities later on.
  2. Clear Requirements for Developers: Security User Stories provide clear, actionable security requirements, helping developers understand exactly what is expected to make the software secure.
  3. Accountability: Writing security stories holds the development team accountable for implementing security features and allows for better tracking of security tasks within the development cycle.
  4. Risk Mitigation: When security is considered early in the SDLC, potential security issues are identified and addressed before they become significant risks. This aligns with the concept of “Shift Left” security, where security is integrated into earlier stages of the development process.

How to Use Security User Stories

Security User Stories should be written as part of the Product Backlog and prioritized based on the level of risk or impact. Here’s how to use them effectively:

  1. Collaboration with Security Experts: Work with security professionals to identify potential threats and risks specific to the application or platform. They can help create and refine security user stories based on threat modeling and vulnerability assessments.
  2. Define Acceptance Criteria: Each Security User Story should have clear, testable acceptance criteria. These criteria define when the story is considered complete and what tests should be performed to verify the security requirement has been met.
  3. Prioritize Based on Risk: Security User Stories should be prioritized just like functional features, based on their importance. Stories that address high-risk vulnerabilities, such as authentication or encryption, should be prioritized early in the development cycle.
  4. Regular Review and Updates: Security is an evolving field. As new threats emerge, Security User Stories should be reviewed and updated to address the latest vulnerabilities. Regular threat assessments help ensure the backlog remains current.

Examples of Security User Stories Across Different Platforms

1. Web Application Development

Web applications face numerous security threats, from SQL injection to Cross-Site Scripting (XSS). Below are examples of Security User Stories that address common web application security issues:

  • “As a user, I want my password to be stored securely using a strong hashing algorithm like bcrypt, so that my account is protected from unauthorized access.”
  • “As a system, I want to validate all user inputs server-side to prevent injection attacks.”
  • “As a system, I must use HTTPS for all data transmitted between the client and the server, to ensure data confidentiality.”
  • “As a user, I want to be logged out after 15 minutes of inactivity, so that my session cannot be hijacked.”

2. Windows Software Development

Windows software may face risks such as privilege escalation or malicious code execution. Security User Stories for Windows development could include:

  • “As a user, I want my application to run with the minimum necessary privileges, so that the system is protected from privilege escalation attacks.”
  • “As a system administrator, I want all logs to be stored securely and be tamper-proof, so that I can audit user activities reliably.”
  • “As a developer, I want the application to verify all digital signatures before executing code, to ensure the code has not been tampered with.”
  • “As a system, I want to enforce Data Execution Prevention (DEP) to prevent malicious code from executing in the memory.”

3. Android App Development

Mobile applications, particularly Android apps, face unique security challenges, such as improper storage of sensitive information and unauthorized access to device features. Examples of Android-related Security User Stories include:

  • “As a user, I want my sensitive data (e.g., passwords, payment information) to be encrypted using the Android Keystore system, so that my data is safe even if the device is compromised.”
  • “As a developer, I want the app to request only the necessary permissions, so that the user’s privacy is respected.”
  • “As a user, I want to be required to authenticate using biometrics before making sensitive changes, such as resetting my password, to ensure the security of my account.”
  • “As a system, I want to securely store session tokens and prevent them from being accessible via insecure storage mechanisms (e.g., SharedPreferences).”

4. iOS App Development

iOS apps must adhere to strict privacy and security guidelines, and improper handling of user data can lead to severe breaches. Below are Security User Stories specific to iOS development:

  • “As a user, I want all sensitive information (e.g., authentication tokens) to be stored in the iOS Keychain, so that my data is protected from unauthorized access.”
  • “As a system, I want to ensure that network communication is secured using TLS 1.2 or above, to protect against man-in-the-middle attacks.”
  • “As a user, I want to enable Face ID for sensitive transactions (e.g., payments), to ensure that unauthorized users cannot perform critical actions.”
  • “As a developer, I want to implement App Transport Security (ATS) to ensure all connections are encrypted.”

Conclusion

Security User Stories are a powerful tool for developers to integrate security into their development process. By writing clear, actionable stories with defined acceptance criteria, development teams can proactively address security risks while ensuring that they meet functional requirements.

Whether you’re building a web app, Windows software, or mobile applications for Android or iOS, incorporating Security User Stories into the backlog ensures that security remains a priority throughout the SDLC.

With this approach, developers can create secure, reliable software that meets the needs of both the business and the users.

The post How-To create Security User Stories first appeared on Sorin Mustaca on Cybersecurity.

Understanding Defense in Depth in IT Security

/in

The recent outage caused by Crowdstrike’s faulty update has create a lot of discussions. I wrote a post on LinkedIn where I asked the readers why are IT professionals using Crowdstrike on some systems that shouldn’t be in need of such protection in the first place.

The answers in various groups were mostly related to:

  • protect everything against everyone
  • assume the worse
  • assume that you are compromised.

I do not agree with such a shallow answer. And this raises a question about Defense in Depth.

Defense in Depth

Defense in Depth is a cybersecurity strategy that employs multiple layers of security controls to protect an organization’s assets and information. This approach is based on the premise that no single security measure is foolproof. By implementing several layers of defense, even if one control fails, others are in place to mitigate risks. The concept is inspired by military defense strategies, where a series of defensive positions are used to delay or prevent an attack.

A common misconception about Defense in Depth is that it requires identical security measures across all layers of an IT environment. In reality, this is neither necessary nor practical. Different layers have different requirements based on their specific functions, vulnerabilities, and the types of threats they are exposed to. Applying the same controls universally can lead to inefficiencies, increased costs, and potential performance issues.

In my opinion, this is what happened in many cases during the Crowdstrike outage: admins installed the EDR solution simply on all available devices, without doing an analysis of the threats they are exposed to. This is called threat modeling, and the first step after identifying the assets to protect is to analyze their threat landscape: this is the set of threats they are potentially exposed to. Once the potential threats are identified, then the appropriate security controls can be defined. But, it is important that the right controls are used based on the risk level of the potential threat. The mistake here is that people try to protect against any potential risk, no matter how improbable it might be. So, it is not worth to protect against every potential risk.

But, this operation is, at least at first sight, expensive, time consuming and very few people know how to do it.

So, what happens in most cases is that people consider to be cheaper to buy additional licenses and accept easily a slight reduction in performance due to the tool monitoring everything (“throw” more hardware on it).

And this might be OK, if everything works perfect all the time. Well, it doesn’t !

If this sounds too theoretical, then let’s have a closer look at various layers where applications run.

  • Running at the Web Application Layer: This layer might need strong authentication mechanisms, input validation, and encryption to protect against web-based attacks such as SQL injection or cross-site scripting (XSS).
  • Running at the Network Layer: Here, firewalls, intrusion detection systems (IDS), and virtual private networks (VPNs) are more appropriate to guard against network-based threats like DDoS attacks or unauthorized access.
  • Running at the Endpoint Layer: Devices such as laptops and mobile phones might require antivirus software, device encryption, and endpoint detection and response (EDR) solutions to prevent malware infections and data breaches.

Each layer of security addresses different risks, and the controls should be tailored to the specific threats and the environment.

For instance, a high-value database containing sensitive customer information might warrant multiple layers of encryption, strict access controls, and regular auditing. In contrast, a low-value, non-critical application might only require basic security measures.

Of course, there are applications having parts that run on more than one layer. When this happens, then you must correctly create the threat model and identify the risks at each layer.

For example, if you have a computer which just displays flights schedules, without having an interaction with the exterior other than retrieving data from an internal webservice, you probably do not need a dedicated endpoint security product for it.

Why? Because you will not allow access to the machine other than the service account for patches and running the required software.

If you’re unsure, and the machine runs Windows, than the default Defender is more than enough.

Create a Threat Model for your endpoints

If you don’t know how to create a threat model for an endpoint (and not only Windows, MacOS and Linux are equally affected), here is a list of potential threats and their mitigations.

Important note:
If you apply correctly the principles of Defense in Depth, you will NEVER all all these potential risks applicable to your devices.

Even if you remotely consider that some or all these risks can occur, do not forget that the Risk is proportional to the Probability of occurrence and Impact effect:

  • Probability of occurrence – what are the chances that the risk actually occurs: Very probably, Probably, Sometimes, Unlikely, Never.
  • Impact effect: Catastrophic, Very high, High, Medium, Low.

Potential Risks on an Endpoint

  • Malware Infections

    • Risk: Viruses, Trojans, ransomware, spyware, and other malicious software can compromise the system.
    • Security Controls:
      • Antivirus/anti-malware software
      • Regular system scans and updates
      • Application whitelisting
      • Sandboxing suspicious files
      • Backup with versioning control (good for ransomware attacks)

  • Unpatched Software

    • Risk: Vulnerabilities in outdated software can be exploited by attackers.
    • Security Controls:
      • Automated patch management systems with rollback functionality
      • Regular software updates
      • Vulnerability scanning tools
      • Centralized patch distribution

  • Unauthorized Access

    • Risk: Unauthorized users may gain access to the endpoint, leading to data breaches or system compromise.
    • Security Controls:
      • Strong password policies
      • Multi-factor authentication (MFA)
      • User account control (UAC)
      • Role-based access controls (RBAC)

  • Data Theft

    • Risk: Sensitive data may be copied, transmitted, or stolen from the endpoint.
    • Security Controls:
      • Full disk encryption (e.g., BitLocker)
      • Data loss prevention (DLP) tools
      • USB port control and removable media encryption
      • Secure backup solutions

  • Physical Theft

    • Risk: The endpoint itself may be physically stolen, leading to loss of data and access to the network.
    • Security Controls:
      • Physical security measures (locks, secure storage)
      • Device tracking and remote wipe capabilities
      • Full disk encryption
      • BIOS/UEFI passwords

  • Drive-by Downloads

    • Risk: Malicious websites may automatically download and install malware without user consent.
    • Security Controls:
      • Web filtering and browser security plugins
      • Regular updates to browsers and plugins
      • Application whitelisting
      • Disabling automatic execution of scripts in browsers

  • Network-based Attacks

    • Risk: Attackers may exploit vulnerabilities in the network to compromise the endpoint.
    • Security Controls:
      • Personal firewall
      • Network segmentation
      • Secure VPN connections
      • Intrusion detection and prevention systems (IDPS)

  • Misconfigured Security Settings

    • Risk: Insecure configurations can leave the endpoint vulnerable to attacks.
    • Security Controls:
      • Regular security audits and compliance checks
      • Hardening guides and best practices (e.g., CIS benchmarks)
      • Group policies for centralized management
      • Security baselines and templates

Potential Human Risks

Phishing Attacks

  • Risk: Users may be tricked into divulging sensitive information or downloading malicious software through deceptive emails or websites.
  • Security Controls:
    • Email filtering with anti-phishing capabilities
    • User awareness training
    • Web filtering and reputation services
    • Multi-factor authentication (MFA)

Insider Threats

  • Risk: Malicious or negligent insiders may intentionally or unintentionally cause harm.
  • Security Controls:
    • User activity monitoring and logging
    • Least privilege principle
    • Endpoint detection and response (EDR)
    • Insider threat detection tools

Instead of conclusion: Balancing Security and Usability

The most critical aspect of Defense in Depth is balancing security and usability.

Over-securing can lead to decreased productivity, increased costs, and user dissatisfaction.

For instance, implementing multi-factor authentication (MFA) at every step might significantly slow down legitimate users, leading to frustration and potential workarounds that can undermine security.

A well-designed Defense in Depth strategy finds the right balance by applying strict controls where necessary and lighter measures where the risk is lower.

The goal is to create a robust security posture that protects against a wide range of threats without overburdening the system or its users.

 

The post Understanding Defense in Depth in IT Security first appeared on Sorin Mustaca on Cybersecurity.

ISO 27001:2022 and TISAX: overlaps and differences

/in

Introduction

ISO 27001:2022 and TISAX VDA ISA 6.0 are two prominent standards in the realm of information security management, particularly within the automotive industry. While ISO 27001 provides a global framework for establishing, implementing, maintaining, and continually improving an information security management system (ISMS), TISAX (Trusted Information Security Assessment Exchange), based on the VDA ISA (Information Security Assessment) framework, is tailored to meet the specific needs of the automotive sector.

This article delves into the nuances of these two standards, highlighting their overlaps, the ways in which TISAX leverages ISO 27001, and the distinct features that set TISAX apart.

Overview of ISO 27001:2022

ISO 27001:2022 is the latest revision of the internationally recognized standard for information security management. It provides a comprehensive approach to managing sensitive company information so that it remains secure. This involves a risk management process, which includes people, processes, and IT systems by applying a risk management process.

Key Features of ISO 27001:2022

  • Risk-Based Approach: Emphasizes the identification and management of risks through a continuous improvement process.
  • Annex A Controls: Contains 93 controls categorized under four themes: Organizational, People, Physical, and Technological.
  • PDCA Cycle: The Plan-Do-Check-Act cycle is integral for continuous improvement.
  • Context of the Organization: Requires understanding of internal and external factors impacting information security.
  • Leadership Commitment: Highlights the importance of top management’s involvement in the ISMS.

Overview of TISAX VDA ISA 6.0

TISAX, a standard specific to the automotive industry, is based on the VDA ISA (Verband der Automobilindustrie Information Security Assessment) catalog. TISAX ensures that automotive manufacturers and suppliers meet strict information security requirements to protect sensitive information.

Key Features of TISAX VDA ISA 6.0

  • Sector-Specific: Tailored specifically for the automotive industry.
  • VDA ISA Catalog: Based on the VDA ISA framework, which is a detailed checklist of requirements and controls. It is split in several areas of interest:
    • Information security – containing everything that belongs to an ISMS
      • IS Policies and Organization
      • Information Security Policies
      • Organization of Information Security
      • Asset Management
      • IS Risk Management
      • Assessments
      • Incident and Crisis Management
      • Human Resources
      • Physical Security
      • Identity and Access Management
      • Identity Management
      • Access Management
      • IT Security / Cyber Security
      • Cryptography
      • Operations Security
      • System acquisitions, requirement management and development
      • Supplier Relationships
      • Compliance
    • Prototype Protection – focused on physical and cyber protection of prototypes
    • Data Protection – focused on policies for protecting privacy and secrets
  • Assessment Levels: Comprises different levels of assessment depending on the type of information and its criticality.
  • Labeling System: Provides a TISAX label indicating compliance, which can be shared with partners within the automotive ecosystem.
  • Focus on KPIs: VDA ISA provides a large set of examples on how to measure certain controls effectively.

Overlaps between ISO 27001:2022 and TISAX VDA ISA 6.0

While TISAX and ISO 27001 serve different purposes, they share several common elements. TISAX leverages the fundamental principles of ISO 27001, creating a robust framework that is both comprehensive and specific to the automotive sector.

In the VDA ISA 6.x (and previous) there are the columns “Reference to other standards” (column P) and “Reference to implementation guidance” (column Q) which point to known standards. Of course, there is no coincidence that the most reference standard is the ISO 27001 in both versions 2022 and 2013.

In the guidance we usually see reference to the Annex A of the ISO 27001 standard (both versions).

 

In the column W there is “Further information” containing explanations of what can be described by the respective control.

Risk Management

Both ISO 27001 and TISAX emphasize a risk-based approach to information security. ISO 27001 mandates a formal risk assessment process, while TISAX incorporates this through the VDA ISA requirements, ensuring that organizations identify and manage risks relevant to the automotive industry.

Control Objectives and Controls

ISO 27001:2022 and TISAX VDA ISA 6.0 share a common structure in terms of control objectives and specific controls. Many of the controls listed in Annex A of ISO 27001 are reflected in the VDA ISA catalog, ensuring a comprehensive approach to securing information.

While this is a common trait shared by the standards, the TISAX is making use of other standards than ISO 27001: NIST, BSI other ISO standards.

Continuous Improvement

Both standards advocate for continuous improvement. ISO 27001’s PDCA cycle and TISAX’s periodic reassessment and updating of security measures ensure that organizations continually enhance their security posture in response to evolving threats.

TISAX VDA ISA has a sheet called “Maturity Levels” containing descriptions of the Maturity Levels 0 to 5.

Documentation and Record-Keeping

ISO 27001 requires detailed documentation of the ISMS, including risk assessments, policies, and procedures. TISAX also mandates thorough documentation as part of its assessment criteria, ensuring that organizations maintain a clear record of their security practices.

Third-Party Management/Suppliers Relationships

Third-party risk management is a critical component in both standards. ISO 27001 includes controls for managing supplier relationships and ensuring their compliance with information security requirements. Similarly, TISAX places a strong emphasis on securing information exchanged with suppliers and partners, crucial for maintaining the integrity of the automotive supply chain.

Differences between ISO 27001:2022 and TISAX VDA ISA 6.0

Despite their overlaps, ISO 27001 and TISAX have several distinctions, reflecting their different scopes and target audiences.

Industry Focus

ISO 27001 is a generic standard applicable to any organization, regardless of its sector. TISAX, however, is designed specifically for the automotive industry, addressing unique challenges such as the secure exchange of data between manufacturers and suppliers.

Assessment Process

ISO 27001 involves a formal certification process conducted by accredited bodies, leading to ISO 27001 certification. TISAX, on the other hand, employs a mutual assessment model where organizations are assessed by ENX approved audit providers, and successful assessments result in a TISAX label. This label can then be shared with other automotive industry stakeholders, facilitating trust and compliance.

Control Specificity

While ISO 27001 provides a broad framework of controls applicable to various industries, TISAX’s controls are highly specific to the automotive sector. The VDA ISA catalog includes detailed requirements for protecting manufacturing data, ensuring compliance with industry-specific regulations, and safeguarding automotive intellectual property.

Levels of Assessment

TISAX introduces different levels of assessment (Basic(Must and Should), High, and Very High) depending on the sensitivity and criticality of the information being protected. ISO 27001 does not have a tiered assessment system but rather a uniform certification standard.

Focus Areas

TISAX places significant emphasis on physical security, secure development of automotive products, and compliance with industry-specific legal requirements. ISO 27001, while comprehensive, does not delve into sector-specific issues with the same level of detail.

Commercial vs Open standards

ISO 27001 is an open international standard governed by the Internation Standards Organisation (ISO). The TISAX trademark is owned by the organization ENX, formed by many OEMs in automotive sector.

 

Implementation of TISAX Using ISO 27001

TISAX leverages ISO 27001’s framework to build a robust and industry-specific information security system. Many organizations begin with ISO 27001 certification and then adapt their ISMS to meet the additional requirements of TISAX.

Integration of Standards

  1. Foundation in ISO 27001: Organizations often establish a basic ISMS in accordance with ISO 27001. This includes conducting risk assessments, implementing controls, and ensuring continuous improvement.
  2. Customization to TISAX Requirements: Once the foundational ISMS is in place, organizations tailor it to meet TISAX requirements, which may involve additional controls specific to automotive data security and third-party management.
  3. Assessment and Labeling: Organizations undergo a TISAX assessment conducted by an approved audit provider. Successful completion results in the issuance of a TISAX label, demonstrating compliance with industry-specific security requirements.

Benefits of Integration

Integrating ISO 27001 with TISAX offers several benefits:

  • Streamlined Compliance: Simplifies the process of meeting both generic and sector-specific security requirements.
  • Enhanced Trust: The TISAX label, backed by ISO 27001’s rigorous framework, enhances trust among automotive industry partners.
  • Cost Efficiency: Leveraging ISO 27001 as a foundation reduces duplication of effort and resources in implementing security measures.

Conclusion

ISO 27001:2022 and TISAX VDA ISA 6.0 represent critical standards for information security, particularly within the automotive sector. While they share common principles such as risk management and continuous improvement, TISAX’s industry-specific focus and detailed requirements for automotive set it apart. By leveraging the robust framework of ISO 27001, organizations can start to effectively implement TISAX, ensuring comprehensive protection of sensitive automotive data and fostering trust within the industry.

Understanding the connections between these standards and their unique requirements is very important for organizations aiming to achieve a high level of information security and compliance.

The post ISO 27001:2022 and TISAX: overlaps and differences first appeared on Sorin Mustaca on Cybersecurity.

NIS-2: 10 common misconceptions about the regulation

/in

We wrote here about NIS2 and we will continue to add more content about it.

Because we are getting closer to October 17th, many people are getting more and more nervous about NIS2.

Despite its significance, there are numerous misconceptions and misinterpretations circulating about the scope and implications of this regulation.

This article aims to clarify some of the misconceptions,  which I collected mostly from LinkedIn and articles about NIS-2.

 

Note:

“NIS2” and “NIS-2” are exactly the same thing. I am using both in this article only because of SEO.

 

 

1. NIS2 starts being applied in the EU starting 17.10.2024

Truth is that the regulation is already applicable in the EU since it was approved. This deadline applies to the individual countries of the EU to convert and apply the NIS2 requirements in local laws.

If national authorities fail to properly implement EU laws, the Commission may launch a formal infringement procedure against the country in question. If the issue is still not settled, the Commission may eventually refer the case to the Court of Justice of the European Union.

 

2. Limited scope of application

Contrary to the belief that NIS-2 only applies to large tech companies, the directive significantly broadens its scope compared to its predecessor, NIS.

NIS-2 extends beyond just critical infrastructure sectors like energy and transport, encompassing a wide array of sectors such as digital services, public administration, and healthcare.

It mandates a security and incident reporting framework that applies to both Essential and Important Entities, significantly expanding the list of sectors and services affected.

3. NIS-2 Is Just About Cybersecurity

While cybersecurity is a core component, NIS-2 is not merely about preventing cyberattacks. The directive emphasizes a comprehensive approach to security, which includes resilience against a wide range of threats.

This includes but it is not limited to:

  • supply chain security,
  • incident response, and
  • crisis management.

It establishes a baseline for security measures and incident notifications that entities must adhere to, ensuring a uniform level of security across member states.

4. NIS-2 compliance is the same across all EU countries

Although NIS-2 sets a framework for cybersecurity across the EU, member states have some flexibility in implementation. This means that there can be variations in how directives are enforced from one country to another, depending on local laws and regulations.

Companies operating across multiple jurisdictions need to be aware of and comply with local variations to ensure full compliance.

5. Heavy penalties are the main compliance driver

While it is true that NIS-2 can impose hefty fines for non-compliance, focusing solely on penalties misses the broader objective of the directive.

NIS-2 is designed to cultivate a culture of security and resilience. It encourages entities to proactively manage their cybersecurity risks and to collaborate with national authorities.

This cooperative approach is fundamental to enhancing the overall cybersecurity posture of the EU.

6. NIS-2 does not affect third-party suppliers

NIS-2 places explicit requirements on the security practices of third-party suppliers. Entities covered under the directive are required to ensure that their supply chains are secure.

This includes mandatory risk assessments and incident reporting requirements that extend to service providers, reflecting an understanding that security is only as strong as the weakest link in the supply chain.

 

7. NIS-2 contains rules for AI, IoT, Industry 4.0.

NIS-2 sets a framework for cybersecurity and it does not address anything in particular. However, the rules described can be very well applied to companies in the fields like those mentioned that fall under the regulation applicability.

The companies active in Digital Infrastructure Services (Internet Nodes, DNS Service Providers, TLD Registries, Cloud Providers, Data Centers, Content Delivery Networks, Trust Services, Communication Networks, Communication Services ) and in

ICT Service Management (B2B only) (Managed Services (IT, Networks/Infrastructure, Applications), Managed Security Services (Risk and Cyber Security) ) are potentially directly affected by the regulation. However, there are clear criteria about which companies are affected.

 

8. Any company with activity in the domains marked as Important and Essential is affected by NIS-2

Although the domains are under the NIS-2 regulation, a company is affected if it meets the criteria:

  • Essential Entities (EE):
    • at least 250 employees and
    • 50 Mil € revenue
  • Important Entities (IE):
    • at least 50 employees and
    • 10 Mil € revenue

If a company doesn’t have these characteristics, then, in general, it is not affected by the regulation directly. It is highly recommended that even in such cases the companies follow the regulation’s requirements, since it will increase their resilience against cyber attacks.

However, an entity may still be considered “essential” or “important” even if it does not meet the size criteria, in specific cases such as when it is the sole provider of a critical service for societal or economic activity in a Member State.

 

9. All affected companies must certify for NIS-2

A the time of writing this post there is no certification for NIS-2. This might change in the future, especially when because we don’t know at this time how the regulation will be implemented in each of the EU member states.

There are consulting companies that sell consulting services and guarantee that a company will get the “NIS-2  certification” if they bus their services. While buying consulting is in general a good thing, the only thing that can be obtained is help in meeting the requirements of the regulation.

I recommend to stay away from offers that promise things that don’t exist.

 

10. Companies can buy software/hardware products to become conform with NIS-2

Although conformity is sometimes made easier by using specialized software and hardware products, there is no requirement or recommendation to purchase anything.

Some security providers and consulting companies are offering On The Shelf  (OTS) products that promise immediate conformity with NIS-2 (or guarantee obtaining a “certification” – see point 9 above).

If you look at the series of articles in the NIS2 area of this website, you will see that actually quite a lot of  steps involve an ISMS, a cybersecurity framework, cybersecurity products and so on.

These can be implemented with commercial or open source products, but there is still need to know where and how to install them in order to become conform.

I can very well imagine that there will be soon commercial offerings with sets of templates for implementing the NIS-2 requirements, just like there are with ISO 27001, TISAX and other certifications.

The post NIS-2: 10 common misconceptions about the regulation first appeared on Sorin Mustaca on Cybersecurity.

Understanding ISO 27001:2022 Annex A.14 – System Acquisition, Development, and Maintenance

/in

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.14, “System Acquisition, Development, and Maintenance”, which addresses the importance of ensuring the security of information systems throughout their lifecycle, from acquisition and development to maintenance and disposal. This annex provides guidelines for implementing controls to manage the security of information systems and software applications.

 

 

Importance of System Acquisition, Development, and Maintenance

System acquisition, development, and maintenance are critical stages in the lifecycle of information systems and software applications. Annex A.14 underscores this importance by:

  1. Security by Design: Integrating security considerations into the acquisition, development, and maintenance processes helps identify and mitigate security risks early in the lifecycle, reducing the likelihood of vulnerabilities and security incidents.
  2. Secure Development Practices: Implementing secure coding practices, testing methodologies, and vulnerability management processes helps ensure the integrity, confidentiality, and availability of software applications and systems.
  3. Change Management: Managing changes to information systems and software in a controlled manner helps prevent unauthorized modifications, configuration errors, and disruptions to services.

Implementing Annex A.14 in Practice

To effectively implement Annex A.14, organizations can follow these practical steps:

  1. Security Requirements Analysis: Conduct a security requirements analysis during the system acquisition phase to identify security requirements and considerations for information systems and software applications.

    Example: Include security requirements such as authentication mechanisms, access controls, encryption, and audit logging in the procurement specifications for new information systems or software applications.

  2. Secure Development Practices: Adopt secure coding guidelines, frameworks, and best practices during the development phase to minimize the risk of security vulnerabilities and weaknesses in software applications.

    Example: Implement input validation, output encoding, and proper error handling to mitigate common vulnerabilities such as cross-site scripting (XSS), SQL injection, and buffer overflows in web applications.

  3. Vulnerability Management: Implement vulnerability scanning, penetration testing, and code reviews to identify and remediate security vulnerabilities and weaknesses in information systems and software applications.

    Example: Conduct regular vulnerability scans and penetration tests of network infrastructure, web applications, and databases to identify security vulnerabilities and prioritize remediation efforts.

  4. Change Control: Establish change management procedures to control and document changes to information systems and software applications in a controlled and auditable manner.

    Example: Implement a change management system to track and manage changes to software code, configurations, and configurations, ensuring that changes are reviewed, approved, and tested before deployment.

  5. Patch Management: Implement patch management processes to identify, assess, and apply security patches and updates to information systems and software applications in a timely manner.

    Example: Establish a patch management schedule to regularly assess and apply security patches and updates to operating systems, software applications, and firmware to mitigate security vulnerabilities and risks.

Audit of Compliance with Annex A.14

Auditing compliance with Annex A.14 is essential for evaluating an organization’s adherence to system acquisition, development, and maintenance requirements. Here’s how the audit process typically unfolds:

  1. Audit Preparation: Gather documentation related to system acquisition, development, and maintenance policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
  2. Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
  3. On-site Audit: Conduct on-site visits to assess implementation of system acquisition, development, and maintenance controls. Review documentation, inspect development environments, and observe change management practices. Use checklists or assessment tools to evaluate compliance.
  4. Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in system acquisition, development, and maintenance implementation.
  5. Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
  6. Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.14 emphasizes the importance of ensuring the security of information systems throughout their lifecycle. By implementing controls and best practices for system acquisition, development, and maintenance, organizations can minimize security risks, vulnerabilities, and incidents. Regular audits help assess compliance with Annex A.14 requirements and drive continuous improvement in system security practices.

The post Understanding ISO 27001:2022 Annex A.14 – System Acquisition, Development, and Maintenance first appeared on Sorin Mustaca on Cybersecurity.

Understanding ISO 27001:2022 Annex A.13 – Communications Security

/in

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.13, “Communications Security”, which addresses the importance of securing information during its transmission over communication networks.

This annex provides guidelines for implementing controls to protect the confidentiality, integrity, and availability of information exchanged between parties.

 

 

Importance of Communications Security

Communications security is crucial for safeguarding sensitive information transmitted over communication channels, such as networks, internet connections, and wireless technologies. Annex A.13 underscores this importance by:

  1. Confidentiality: Encrypting communications prevents unauthorized parties from intercepting and eavesdropping on sensitive information transmitted over unsecured networks.
  2. Integrity: Implementing integrity checks and digital signatures ensures that transmitted data remains intact and unaltered during transit, protecting against tampering and unauthorized modifications.
  3. Availability: Securing communication channels helps maintain the availability of information services and prevents disruptions caused by network attacks, denial-of-service (DoS) attacks, or transmission errors.

Implementing Annex A.13 in Practice

To effectively implement Annex A.13, organizations can follow these practical steps:

  1. Encryption: Encrypt data transmitted over insecure communication channels using encryption protocols such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), or Virtual Private Network (VPN) tunnels.Example: Configure email servers to use TLS encryption for encrypting emails in transit between email clients and servers, preventing eavesdropping on email communications.
  2. Digital Signatures: Use digital signatures to verify the authenticity and integrity of transmitted data and messages. Implement digital signature algorithms and certificate authorities to ensure the validity of signatures.Example: Digitally sign electronic documents, such as contracts or reports, using a digital signature certificate issued by a trusted certificate authority to verify the authenticity and integrity of the documents.
  3. Secure Protocols: Use secure communication protocols and standards, such as Secure Shell (SSH), Hypertext Transfer Protocol Secure (HTTPS), and Internet Protocol Security (IPsec), to protect data transmitted over networks.Example: Configure web servers to use HTTPS protocol for secure transmission of sensitive information, such as login credentials or financial transactions, over the internet.
  4. Access Controls: Implement access controls to restrict access to communication channels and network resources to authorized users only. Use strong authentication mechanisms to verify the identity of users accessing network services.Example: Configure network routers and firewalls to enforce access control lists (ACLs) restricting inbound and outbound traffic based on source and destination IP addresses, ports, and protocols.
  5. Monitoring and Logging: Deploy monitoring and logging mechanisms to track communication activities, detect anomalies, and identify potential security incidents or unauthorized access attempts.Example: Set up network intrusion detection systems (NIDS) or intrusion prevention systems (IPS) to monitor network traffic for suspicious behavior, such as port scans or packet sniffing attempts.

Audit of Compliance with Annex A.13

Auditing compliance with Annex A.13 is essential for evaluating an organization’s adherence to communications security requirements. Here’s how the audit process typically unfolds:

  1. Audit Preparation: Gather documentation related to communications security policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
  2. Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
  3. On-site Audit: Conduct on-site visits to assess implementation of communications security controls. Review documentation, inspect network configurations, and observe communication practices. Use checklists or assessment tools to evaluate compliance.
  4. Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in communications security implementation.
  5. Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
  6. Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.13 emphasizes the importance of communications security in protecting sensitive information transmitted over communication networks. By implementing robust controls and measures to encrypt data, verify authenticity, and enforce access controls, organizations can mitigate risks and safeguard against unauthorized access or interception of communications. Regular audits help assess compliance with Annex A.13 requirements and drive continuous improvement in communications security practices.

The post Understanding ISO 27001:2022 Annex A.13 – Communications Security first appeared on Sorin Mustaca on Cybersecurity.

Understanding ISO 27001:2022 Annex A.12 – Operations Security

/in

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

Today we address ISO 27001:2022 Annex A.12, “Operations Security”, which focuses on ensuring secure operations of information systems and assets. This annex provides guidelines for implementing controls to manage day-to-day operations, protect against security incidents, and maintain the integrity, availability, and confidentiality of information assets.

 

Importance of Operations Security

Operations security is critical for maintaining the effectiveness and resilience of information systems and assets. Annex A.12 underscores this importance by:

  1. Risk Management: Implementing operational controls helps identify, assess, and mitigate risks to information assets, ensuring business continuity and protecting against security incidents.
  2. Incident Response: Establishing incident response procedures enables organizations to detect, respond to, and recover from security incidents effectively, minimizing the impact on operations and data integrity.
  3. Change Management: Managing changes to information systems and assets in a controlled manner helps prevent unauthorized modifications, configuration errors, and disruptions to services.

Implementing Annex A.12 in Practice

To effectively implement Annex A.12, organizations can follow these practical steps:

  1. Risk Assessment: Conduct regular risk assessments to identify potential threats, vulnerabilities, and risks to information assets. Assess the likelihood and impact of identified risks to prioritize mitigation efforts.Example: Perform a comprehensive risk assessment of IT systems, networks, and applications to identify vulnerabilities, such as outdated software or misconfigured settings, that could expose assets to security threats.
  2. Incident Management: Establish incident response procedures to define roles, responsibilities, and actions to be taken in the event of a security incident. Develop incident response plans, escalation procedures, and communication protocols.Example: Develop an incident response playbook outlining steps to be followed in case of a security breach, including incident detection, containment, eradication, recovery, and post-incident analysis.
  3. Monitoring and Logging: Implement monitoring and logging mechanisms to track user activities, detect anomalies, and identify potential security incidents. Collect and analyze log data from information systems, networks, and security devices.Example: Deploy security information and event management (SIEM) systems to aggregate and correlate log data from various sources, enabling real-time monitoring, alerting, and analysis of security events.
  4. Change Control: Establish change management procedures to control and document changes to information systems, applications, configurations, and infrastructure. Define change request processes, approval workflows, and testing requirements.Example: Implement a change management system to track and manage changes to IT assets, including software updates, patches, configuration changes, and infrastructure modifications, following a structured change control process.
  5. Backup and Recovery: Implement backup and recovery procedures to protect against data loss, corruption, and unauthorized access. Regularly back up critical data and systems, and test backup restoration procedures.Example: Configure automated backup schedules for critical databases, files, and systems, ensuring that backup copies are stored securely and can be restored in the event of data loss or system failure.
  6. Protection against malware: Implement detection, prevention and recovery controls to protect against malware, combined with appropriate user awareness training.

Audit of Compliance with Annex A.12

Auditing compliance with Annex A.12 is essential for evaluating an organization’s adherence to operational security requirements. Here’s how the audit process typically unfolds:

  1. Audit Preparation: Gather documentation related to operational security policies, procedures, and controls. Appoint an audit team to facilitate the audit process.
  2. Audit Planning: Define the audit scope, objectives, and criteria. Develop an audit plan outlining activities, timelines, and responsibilities of auditors and auditees.
  3. On-site Audit: Conduct on-site visits to assess implementation of operational security controls. Review documentation, interview personnel, and observe operational practices. Use checklists or assessment tools to evaluate compliance.
  4. Audit Findings: Analyze findings and identify areas of non-compliance or improvement opportunities. Document observations, including strengths and weaknesses in operational security implementation.
  5. Reporting: Prepare an audit report summarizing findings, conclusions, and recommendations for corrective actions. Share with senior management and stakeholders for review and action.
  6. Follow-up: Address audit findings by implementing corrective actions and improvements as recommended. Conduct follow-up audits to verify effectiveness of corrective measures and ensure ongoing compliance.

Conclusion

ISO 27001:2022 Annex A.12 emphasizes the importance of operational security in maintaining the effectiveness, resilience, and integrity of information systems and assets. By implementing robust controls and procedures for risk management, incident response, change control, and backup and recovery, organizations can mitigate risks, protect against security incidents, and ensure business continuity. Regular audits help assess compliance with Annex A.12 requirements and drive continuous improvement in operational security practices.

The post Understanding ISO 27001:2022 Annex A.12 – Operations Security first appeared on Sorin Mustaca on Cybersecurity.

Understanding ISO 27001:2022 Annex A.8 – Asset Management

/in

 

ISO 27001:2022 Annex A.8, “Asset Management,” addresses the importance of identifying, classifying, and managing information assets within an organization. This annex emphasizes the need for organizations to establish processes for inventorying assets, assessing their value, and implementing appropriate controls to protect them. In this technical educational article, we’ll explore how to implement Annex A.8 in practice, highlight its significance, and discuss the audit process for assessing compliance.

 

 

 

 

What is an Asset ?

In the context of ISO 27001:2022, an asset refers to anything that has value to an organization and needs to be protected.

This includes not only tangible assets such as

  • Physical assets:
    • hardware and equipment
    • buildings
    • vehicles
  • People
    • Employees
    • Customers
    • Suppliers
  • Software
  • Intangible
    • Data
    • Intellectual property
    • Proprietary information
    • Reputation
    • Market Share

ISO 27001:2022 recognizes that assets come in various forms and play a crucial role in achieving an organization’s objectives.

What makes an asset worth to be added to the list?

Here are some key points to consider regarding assets in the context of ISO 27001:2022:

  1. Identification: Organizations need to identify and inventory all their assets, including both tangible and intangible ones. This involves understanding what assets the organization possesses, where they are located, and who has ownership or responsibility for them. If this can be done, then the asset is worth enough to be considered to be managed.
  2. Classification: Assets should be classified based on their value, sensitivity, and criticality to the organization. This classification helps prioritize protection efforts and allocate resources effectively. For example, sensitive customer data may be classified as high-value assets requiring stringent security measures. If an asset is classified with a category that makes it important for the company, then it should be definitely managed.
  3. Risk Management: Assets are subject to various risks, including cybersecurity threats, natural disasters, and human error. Organizations need to conduct risk assessments to identify and mitigate threats to their assets effectively. This involves evaluating the likelihood and potential impact of risks and implementing controls to reduce risk to an acceptable level.
  4. Protection: Based on the risk assessment for an asset, organizations must implement appropriate controls to protect their assets from unauthorized access, disclosure, alteration, or destruction. This includes measures such as access controls, encryption, backup procedures, and physical security measures. Based on the measures identified, an asset can be quite expensive to be protected, but losing it or damaging it might prove to be even more expensive.

 

Importance of Asset Management

Effective asset management is crucial for organizations to safeguard their information assets, optimize resource allocation, and mitigate risks. Annex A.8 underscores this importance by:

  1. Risk Reduction: Identifying and classifying information assets helps organizations prioritize security measures and allocate resources effectively to mitigate risks.
  2. Compliance: Maintaining an accurate inventory of assets and implementing appropriate controls ensures compliance with regulatory requirements and industry standards.
  3. Cost Savings: Efficient asset management practices enable organizations to optimize resource utilization and avoid unnecessary expenses associated with redundant or underutilized assets.

Implementing Annex A.8 in Practice

To effectively implement Annex A.8, organizations can follow these practical steps:

  1. Asset Identification: Begin by identifying all information assets within the organization, including hardware, software, data, and intellectual property. Establish criteria for identifying assets, such as ownership, criticality, and sensitivity.Example: Develop an asset inventory list categorizing assets based on their type, location, owner, and importance to business operations.
  2. Asset Classification: Classify information assets based on their value, sensitivity, and criticality to the organization. Define classification levels or categories to differentiate between assets requiring different levels of protection.Example: Classify data assets as public, internal use only, confidential, or restricted based on their sensitivity and impact on the organization if compromised.
  3. Asset Ownership: Assign ownership responsibilities for each information asset to designated individuals or departments within the organization. Clearly define roles and responsibilities for managing and protecting assigned assets.Example: Assign data ownership responsibilities to business units or functional departments responsible for creating, accessing, or managing specific types of data.
  4. Risk Assessment: Conduct risk assessments to identify threats, vulnerabilities, and potential impacts on information assets. Assess the likelihood and impact of potential risks to prioritize mitigation efforts.Example: Perform a vulnerability assessment to identify weaknesses in IT systems and applications that could expose information assets to security threats.
  5. Control Implementation: Implement appropriate controls to protect information assets from unauthorized access, disclosure, alteration, or destruction. Select controls based on the results of risk assessments and compliance requirements.Example: Implement access control mechanisms, such as user authentication, role-based access control (RBAC), and encryption, to safeguard sensitive information assets from unauthorized access.

Audit of Compliance with Annex A.8

Auditing compliance with Annex A.8 is essential for evaluating an organization’s adherence to asset management requirements. Here’s how the audit process typically unfolds:

  1. Audit Preparation: The organization gathers documentation related to asset management policies, procedures, and controls. An audit team is appointed to facilitate the audit process.
  2. Audit Planning: The audit team defines the audit scope, objectives, and criteria. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
  3. On-site Audit: Auditors conduct on-site visits to assess the implementation of asset management controls. They review documentation, interview personnel, and observe asset management practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
  4. Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in the organization’s approach to asset management.
  5. Reporting: Auditors prepare an audit report summarizing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
  6. Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.8 requirements.

Conclusions

ISO 27001:2022 Annex A.8 highlights the importance of asset management in safeguarding information assets and mitigating risks. By implementing robust processes for identifying, classifying, and managing information assets, organizations can optimize resource allocation, ensure compliance, and enhance their security posture. Regular audits help assess compliance with Annex A.8 requirements and drive continuous improvement in asset management practices. Prioritizing asset management is essential for organizations seeking to protect their valuable information assets and maintain trust in their operations.

The post Understanding ISO 27001:2022 Annex A.8 – Asset Management first appeared on Sorin Mustaca on Cybersecurity.

Understanding ISO 27001:2022 Annex A.6 – Organization of Information Security

/in

We started the ISO 27001:2022 series with the promise of explaining how the 14 categories of controls can be implemented.

We start today with ISO 27001:2022 Annex A.6, “Organization of Information Security”, which outlines requirements for establishing an effective management framework to govern information security within an organization. This annex emphasizes the importance of defining roles, responsibilities, and processes to ensure the confidentiality, integrity, and availability of information assets.

In this technical educational article, we’ll explore how to implement Annex A.6 in practice and elucidate the audit process for assessing compliance.

 

Importance of Organization of Information Security

A well-organized approach to information security is essential for maintaining the confidentiality, integrity, and availability of organizational assets. Annex A.6 helps organizations achieve this by:

  1. Defining Responsibilities: Clearly delineating roles and responsibilities ensures accountability for information security tasks across the organization.
  2. Establishing Processes: Formalizing processes for risk management, incident response, and access control streamlines security operations and enhances responsiveness to security incidents.
  3. Ensuring Compliance: Implementing a structured framework for information security governance helps organizations meet regulatory and compliance requirements.

Implementing Annex A.6 in Practice

To effectively implement Annex A.6, organizations can follow these practical steps:

  1. Define Information Security Roles and Responsibilities: Identify key stakeholders responsible for information security governance, including senior management, IT personnel, data owners, and end-users. Clearly define their roles and responsibilities in safeguarding information assets.Example: Establish a Security Steering Committee comprising senior management representatives and department heads to oversee information security initiatives and decision-making.
  2. Develop Information Security Policies and Procedures: Create comprehensive policies and procedures covering areas such as access control, risk management, incident response, and asset management. Ensure alignment with organizational objectives and regulatory requirements.Example: Develop an Incident Response Plan outlining the steps to be followed in the event of a security incident, including incident detection, containment, eradication, and recovery.
  3. Implement Security Controls: Deploy technical and administrative controls to mitigate security risks and protect information assets. These controls may include firewalls, intrusion detection systems, encryption mechanisms, and user access controls.Example: Implement role-based access control (RBAC) to restrict access to sensitive information based on users’ roles and responsibilities within the organization.
  4. Provide Training and Awareness Programs: Educate employees about their roles in maintaining information security and raise awareness about common security threats and best practices. Conduct regular training sessions and awareness campaigns to reinforce security protocols.Example: Offer cybersecurity awareness training to employees covering topics such as phishing awareness, password hygiene, and social engineering tactics.
  5. Establish Security Incident Management Procedures: Develop procedures for reporting, investigating, and responding to security incidents promptly. Define escalation paths and communication channels to ensure swift resolution of incidents.Example: Establish a Security Incident Response Team (SIRT) tasked with coordinating incident response efforts, conducting forensic investigations, and implementing remediation measures.

Auditing Compliance with Annex A.6

Audits play a crucial role in evaluating an organization’s compliance with Annex A.6 requirements. Here’s how the audit process typically unfolds:

  1. Audit Preparation: The organization gathers documentation related to information security policies, procedures, and controls. An audit team is appointed to facilitate the audit process.
  2. Audit Planning: The audit team defines the audit scope, objectives, and criteria. They develop an audit plan outlining the audit activities, timelines, and responsibilities of auditors and auditees.
  3. On-site Audit: Auditors conduct on-site visits to assess the implementation of information security controls. They review documentation, interview personnel, and observe security practices in action. Auditors may use checklists or standardized assessment tools to evaluate compliance.
  4. Audit Findings: After the on-site audit, auditors analyze their findings and identify areas of non-compliance or improvement opportunities. They document their observations, including strengths and weaknesses in the organization’s approach to information security.
  5. Reporting: Auditors prepare an audit report summarizing their findings, conclusions, and recommendations for corrective actions. The report is shared with senior management and relevant stakeholders for review and action.
  6. Follow-up: Management addresses audit findings by implementing corrective actions and improvements as recommended. Follow-up audits may be conducted to verify the effectiveness of corrective measures and ensure ongoing compliance with Annex A.6 requirements.

Conclusion

ISO 27001:2022 Annex A.6 underscores the importance of establishing a structured framework for organizing information security within an organization.

By following best practices for defining roles, responsibilities, processes, and controls, organizations can strengthen their security posture and mitigate risks effectively. Regular audits help assess compliance with Annex A.6 requirements and drive continuous improvement in information security governance.

The post Understanding ISO 27001:2022 Annex A.6 – Organization of Information Security first appeared on Sorin Mustaca on Cybersecurity.

Building Resilient Web Applications on AWS: A Comprehensive Approach to Security

/in

 

I have been asked by friends and customers what is the best way to implement a web based application with minimum costs and good security. Of course, the best way is to define exactly what you want to achieve and let professionals do it, while keeping an eye on the Secure Software Development Lifecycle.

But, this article is not about SSDLC, it is about how to start web application development having also security as a top priority. Securing a classical web application involves a multi-layered approach, addressing the presentation, business logic, and database layers.

Most important thing to keep in mind when engaging into such an enterprise is: don’t try to do everything by yourself – use existing tools and services, which come with a more than decent security built-in.

This article explores how to architect a secure web application on AWS, but it can be applied very well to other cloud based services provider,  and conduct a thorough risk assessment at each level.

A good security approach is to practice defense in depth, meaning that you should check and validate the security of the components used as well. This means that we need to perform at least a high-level risk assessment of these components as well.

 

 

Securing the Presentation Layer

At the forefront of user interaction, the presentation layer demands robust security measures. Amazon CloudFront serves as a reliable content delivery network, ensuring low latency and protection against DDoS attacks.

AWS Identity and Access Management (IAM) steps in to control access to resources at this layer, while AWS Web Application Firewall (WAF) safeguards against common web exploits and secures APIs.

The Presentation layer hosts the UI of the application, typically a website written in HTML5 or a combination of HTML, php, JS, or some high level programming languages that can produce HTML as output.

Such web UIs must be uploaded on a AWS S3 bucket read accessible to everyone and then configure the CloudFront to distribute it.

Risk Assessment at the Presentation Layer

  • Regularly review and adjust IAM policies to mitigate the risk of unauthorized access.
  • Conduct penetration testing on the web application to identify and address vulnerabilities.
  • Monitor CloudFront logs for unusual patterns indicative of a security threat.
  • Make sure nobody has unrestricted access to your S3 bucket hosting the web content

Security practices

  • If you collect data, make sure it is encrypted using AWS Secrets Manager;
  • Do not encrypt using your own keys, hardcoded in your application.
  • Do not invent yourself some “encryption” mechanism, which in the end is just an obfuscation.

Securing the Business Logic Layer

The business logic layer is the heart of a web application, where critical processes take place. Containerizing application logic using AWS Elastic Container Service (ECS) or AWS Fargate ensures enhanced isolation.

AWS Lambda, offering serverless computing, executes sensitive business logic securely. AWS Secrets Manager manages and rotates sensitive API keys and tokens.

Risk Assessment at the Business Logic Layer

– Regularly audit and review AWS Lambda functions to maintain the security of business logic.
– Conduct static and dynamic code analysis to identify vulnerabilities in the application logic.
– Implement AWS CloudWatch for real-time monitoring and alerting on anomalous Lambda function behavior.

Securing the Database Level

The database, housing crucial data, requires robust security measures. Amazon RDS provides secure and scalable relational databases with automatic backups and encryption.

Fine-grained access control through IAM roles and policies is essential for secure database access. AWS Key Management Service (KMS) handles encryption of data at rest within the database.

 

Risk Assessment at the Database Level

– Regularly audit and review database access controls and IAM roles to prevent unauthorized access.
– Implement automated vulnerability scanning tools for the database to identify potential weaknesses.
– Set up AWS CloudTrail to log and monitor all database-related API activity.

 

Continuous Monitoring and Response

Ensuring the ongoing security of a web application involves continuous monitoring and a robust incident response plan. AWS Security Hub acts as a centralized monitoring tool, while AWS Config rules automate the assessment and remediation of non-compliance.

An incident response plan with specific procedures for each layer of the web application architecture ensures a swift and effective response to security incidents.

 

In the next post: risk assessment for the Amazon services used in this article:

  • AWS IAM
  • AWS Elastic Container Service (ECS)
  • AWS Fargate
  • AWS Key Management Service (KMS)
  • AWS Lambda
  • AWS CloudTrail
  • AWS Secrets Manager
  • AWS CloudFront
  • AWS S3

Conclusion

By adopting a comprehensive security strategy across the presentation layer, business logic, and database levels, small organizations can build resilient and cost aware web applications on the AWS platform.

This approach, coupled with regular risk assessments, establishes a solid foundation for web application security, safeguarding against common cybersecurity threats.

The post Building Resilient Web Applications on AWS: A Comprehensive Approach to Security first appeared on Sorin Mustaca on Cybersecurity.