Software development and cloud application security require organization-wide security knowledge and resources.
One of the most frequent cloud security problems is a failure to recognize one’s responsibilities for cloud security.
Secure software development lifecycle ( SDLC ): Requirements, Design, Development, Testing, Deployment, and Operations and Maintenance
- NIST: Prepare the organization, Protect the software, Produce well-secured software and Respond to vulnerabilities.
- OWASP: Governance, Design, Implementation, Verification, and Operations
- Agile software development: Intended to boost the speed and consistency of software delivery.
Secure software development starts with creating a security culture and putting in place a secure software development lifecycle (SDLC). The SSDLC is like a governance document like a security policy, and it should spell out what the organization needs to do and how to do it to develop software securely.
Software Assurance Forum for Excellence in Code (SAFECode)
Cloud Security Alliance (CSA) and SAFECode, collaborative accountability is necessary yet difficult when developing a safety-conscious application development strategy.
This endeavor has three elements.
- Security by design: It’s the Building Security In Maturity Model (BSIMM) and this indicates that security is part of every phase, not just a post-application activity or a reactive response to a fault. At the start of development, all system requirements, including security requirements, should be documented.
- Shared security responsibility: Everyone to management, is responsible for security. Instead, security is the outcome of individual responsibility and trust.
- Security as a business objective: Complying with security can be a barrier for certain companies. However, a security breach can destroy an enterprise. Understanding security threats and mitigating them should be a business objective
Cloud Vulnerabilities
Vulnerabilities in the cloud can range from unauthorized access to data to complete loss of data to unsecured APIs to denial of service attacks. Inherent risks in cloud computing are increased by its reliance on data interchange between systems connected across a network and the ease with which information may be shared between them. The Internet is a dangerous place for any application to access or transfer data.
Cloud Security Alliance (CSA), Open Web Application Security Project (OWASP), Common Weakness Enumeration (CWE/SANS)
Data Breaches
Data breaches target confidentiality, including personal and intellectual property. Data types and security procedures like access restrictions and encryption must be described during requirements collecting. It is important to evaluate these measurements in order to reduce risk depending on the sensitivity and value of the data.
Misconfiguration and inadequate change control
Even if security was established in a secure facility, misconfigurations upon deployment or poor change control methods might lead to security vulnerabilities.
Organizations must set up all security-relevant parameters before deployment. As part of change control, the organization should evaluate proposed changes for security consequences and ensure that implemented changes do not degrade system security.
Lack of cloud security architecture and strategy
After all, cloud computing provides enormous financial benefits for an enterprise, but shifting to the cloud carries serious security risks.
A logical security architecture for cloud computing should include well-documented shared responsibility items and organization-specifics for proper cloud usage given the organization’s particular business operations and data demands.
ISO 27001 emphasises the need of a well-defined security plan and the commitment of top management, two factors that are just as crucial in the cloud.
Insufficient identity, credentials, access, and key management
A well-architected Identity and Access Management strategy are essential to cloud security, and cloud encryption requires strong key and secret management.
Account Hijacking
Taking over another person’s account on a service in order to get access to their data, using their identity to conduct fraud, or both is known as “account hijacking.”
Insider threat
Insider risks can arise from malicious sources like dissatisfied individuals or nonmalicious sources like careless or overworked individuals who make mistakes.
Training and a heightened awareness of security are both essential for reducing the likelihood of careless mistakes. Comprehensive audits and break-the-glass procedures for obtaining emergency administrative authority can also help mitigate some of the threats.
Insecure interfaces and APIs
Securing APIs is crucial as API usage grows. API misconfiguration, bad code, absence of authentication, and inadequate permission are the major causes of incidents and data breaches, thus they must be evaluated for vulnerabilities
Weak control plane
A poor control plane can compromise data confidentiality, availability, and integrity because the system architect or controller has inadequate monitoring or control.
cloud environment and control plane, such as separating production data from development and testing environments.
Metastructure and applistructure failures
Metastructure and application failures are any security operational issues that occur at the cloud provider level. It is critical to understand which portion of the cloud you are accountable for and to remain up to speed on the security procedures your cloud provider is deploying.
Limited cloud usage visibility
Limited cloud use visibility happens when an organization does not have the capability to observe and assess whether or not the use of cloud services within the business is safe or harmful.
Abuse and nefarious use of cloud services
Cloud computing models like IaaS, PaaS, and SaaS are vulnerable to malicious users using inadequately protected cloud service installations, free cloud service trials, and fraudulent account sign-ups
Threat Modeling
As input to risk management, threat modeling helps security professionals spot new threats and vulnerabilities. Threat modeling is useful for prioritizing secure development practices in software development.
PASTA stands for Process for Attack Simulation and Threat Analysis (PASTA)
It will allow you to identify potential threats in your object of scope
STRIDE
Threat modeling is the ultimate shift left. It can find and fix vulnerabilities before writing any code.
- Spoofing Identity: Identify spoofing is a sort of identity theft in which a hacker commits fraud by using the identity and other identifying details of a victim.
- Tampering With Data: Data tampering involves unauthorized changes to data. Bad actors can tamper by altering a configuration file to acquire system control, adding a malicious file, or deleting/modifying a log file.
- Repudiation Threats: Repudiation threats occur when a bad actor engages in an unlawful or harmful activity in a system and subsequently denies involvement in the attack.
- Information Disclosure: Disclosure is also known as leaking data to unauthorized people.
- Denial of Service: DoS attacks prevent authorized users from accessing resources.
- Elevation of Privileges: Privilege escalation allows an attacker to obtain privileged access from an unprivileged account.
DREAD
The DREAD model quantifies threat values to help prioritize remediation. After identifying dangers, the DREAD mnemonic gives questions to rank them.
- Damage: How much would it impact the business if the threat is realized?
- Reproducibility: How easy is it to reproduce an attack?
- Exploitability: Is it a difficult attack to carry out, or does it require significant resources?
- Affected users: How many people may be put at risk if this vulnerability were to be exploited?
- Discoverability: How easily can an attacker find this vulnerability?
PASTA
PASTA integrates security and business objectives in threat modeling and lets security teams apply business impact analysis (BIA).
- Define objectives: During this stage, essential business goals in addition to compliance and security needs are specified.
- Define technical scope: Technical limits are determined in this stage, and any assets inside those limitations must be documented.
- Application decomposition: Analysis is simplified by breaking them down and establishing data and communication flows.
- Threat analysis: Security monitoring tool logs and threat intelligence sources are used for threat analysis. This process identifies system attack vectors.
- Vulnerability analysis: Threats must be connected with system vulnerabilities when they are found. Risk requires a vulnerability and threat to exploit, hence this combination indicates the system’s vulnerabilities.
- Attack modeling: Threat-vulnerability combinations can be modeled and simulated to assess their probability and impact.
- Risk and impact analysis: The Business impact analysis is updated after identifying threats, vulnerabilities, and risks. The identified risks must also be prioritized for remediation depending on their criticality and potential impact on the organization’s operations.
ATASM
Threat modelling process phases are known as ATASM. It may be used with STRIDE, DREAD, or PASTA to analyse threats, and it provides a framework for building or maturing the organization’s threat modelling approach.
- Architecture: Threat modeling begins with a system architecture assessment to help thread model users identify potential attacks and threats.
- Threats: the threat is a malicious attack by an individual or group to obtain network access, damage data, or steal private information.
- Attack surfaces: To put it simply, an attack surface is any aspect of a system that might be targeted by an attacker
- Mitigations: Existing mitigations are evaluated for efficacy and any risks that have not been appropriately mitigated are identified at this stage.
