Cloud Applications Security Checklist

In this article, I write about the few basics of application security all software development teams need to take into account before the application is released.

Cloud Application Security Checklist Before Release. This includes

1. Focus Areas
2. How and Countermeasures
3. Consequences
4. Mapping of Software Resilience to Software Development Lifecycle areas

Let us start with some fun. :-)

Did you happen to know the above before?. Well, it is a silly DoS attack on Unix that my grandma learned in her high school computer science (shell scripting) class. You wouldn't go any far knowing or not knowing about it!.

The human readable version of the program looks something like this:

fork_bomb() { 
 fork_bomb | fork_bomb &
};
fork_bomb

# Remedy: 
# Do  ulimit -S -u 5000 to limit the session to 5000 processes        

Another issue that is harder to replicate and/or diagnose is the below. Most of the software security vulnerability tools wouldn't be able to report this either. So, watch out. One more similar one at the end of this article as well.

• Ensure that Right Permission is given to Right People for the Right Amount of Time for the Right Reasons.
• Enabling the right user under the right conditions to have the right access to the right data.

I made a 'Infographic' image (my 2nd attempt) to make it easy. This is the small component in your entire 'Cloud Security' landscape. This is indeed applicable to any software whether it is deployed in the 'cloud' or 'on-premises' data center.

That is, Security 'in the cloud' of the software service you are responsible for. :-)

The formula is:

RISK = IMPACT × PROBABILITY where,

• Risk: Extent to which an organization is threatened by a potential event.
• Impact: Magnitude of harm expected from the consequences of the event.
• Probability: The likelihood that a threat event will occur.

Another formula is:

Risk = Threat x Vulnerability x Consequence

Ask yourself a question now.

While the following is known and agreed by most companies and folks, hardly companies and teams adhere to this, because, it is due to it won't happen to me mentality. :-). And then when things do go bad, your 'management's' preoccupation to 'make decision' (perhaps a pathological compulsion) and not practicing deference to expertise or not being sensitive to operations would not lead to cultivate a resilience team. (ADVICE).

And if you don't trust above information, have you happened to have studied and remembered the research article (based on true events) that is aptly titled as 'nobody gets credit for fixing a problem that never happened'. That is, your own security people wouldn't bother to make improvements. Just like how your Agile dev team doesn't fix an issue before a Story is created, groomed, discussed and added to a 'Sprint' with appropriate Story-Points _after_ it's been discovered and reported by Customer and designated as a Urgent_and_Important and so on. Sounds familiar??. (yeah! get out of that sick and toxic environment and surround yourself within a better environment). [Food for thought].

To create a more resilient and secure environment, organizations need to do the following:

• Embrace a proactive approach to security. This means taking steps to prevent security incidents from occurring in the first place.
• Recognize and reward security teams for their work. This will encourage them to take ownership of security and make proactive improvements.
• Promote open communication and collaboration: Encourage employees to report security concerns without fear of reprisal, and foster a culture of open communication between security teams and other departments.
• Defer to security expertise. Security teams have the knowledge and experience to make informed decisions about security.
• Be sensitive to operational considerations. Security decisions should not be made in isolation. They should be made in consultation with the people who will be affected by them.

By taking these steps, organizations can create a more secure and resilient environment that is better equipped to protect itself from the ever-evolving threat landscape.

Did you know?

The CWE system allows people to refer to software weaknesses. The CAPEC system allows people to refer to attack patterns. CVE identifiers enable people to get globally unique identifiers for vulnerabilities to refer to them. CVSS (there are several flavors!) allows you to get an idea about the potential severity of a specific vulnerability and to customize the score according to your own IT landscape. As a software application security professional, you should know these. :-)

Software Architecture and Design Review Areas Checklist

• Authentication

• Authorization

• Configuration management

• Sensitive data

• Session management

• Cryptography

• Parameter manipulation

• Exception management

• Auditing and logging

This picture (depicting a simple 3-tiered Web Application) shows the typical places the above mentioned issues could be identified.

Application Security and Resilience Principles

Software Resilience is the ability to reduce the magnitude and/or duration of  disruptive events. The effectiveness of a resilient application or infrastructure  software depends upon its ability to anticipate, absorb, adapt to, and/or  rapidly recover from a potentially disruptive event.

1. Apply defense in depth.

2. Use a positive security model.

3. Fail securely.

4. Run with least privilege.

5. Avoid security by obscurity.

6. Keep security simple.

7. Detect intrusions.

8. Don’t trust infrastructure.

9. Don’t trust services.

10. Establish secure defaults.

Defense In Depth

• Data: Controls that protect the actual data with technologies such as encryption, data leak prevention, identity and access management and data controls.
• Application: Controls that protect the application itself with technologies such as data leak prevention, application firewalls and database monitors.
• Host: Every control that is placed at the endpoint level, such as antivirus, endpoint firewall, configuration and patch management.
• Internal network: Controls that are in place to protect uncontrolled data flow and user access across the organizational network. Relevant technologies include intrusion detection systems, intrusion prevention systems, internal firewalls and network access controls.
• Perimeter: Controls that protect against unauthorized access to the network. This level includes the use of technologies such as gateway firewalls, honeypots, malware analysis and secure demilitarized zones (DMZs).
• Physical: Controls that provide a physical barrier, such as locks, walls or access control.
• Policies, procedures and awareness: Administrative controls that reduce insider threats (intentional and unintentional) and identify risks as soon as they appear. 

Defense In Depth

Development Best Practices that Maps to Software Resilience Table

(NFR - Non Functional Requirement. Quirky way the IT folks have defined that terms!!).

I welcome your comments, suggestions and feedback about this article.

Examples of a couple of practical issues that you may have to deal with below. :-)

What's the deal here? Time of Check/Time of Use (TOC/TOU) is another silly timing vulnerability that is exploited by a threat-agent when a program checks access permissions too far in advance of a resource request. In the above example the threat-agent could replace the file between access check and opening.

Notes:

Authentication - Verifying Identity

Authorization - Verifying permissions

How are these done?.

There are many options and there are many companies and standards providing solutions and suggestions. It is a thriving industry.

Quick Note on Threat Modeling

It goes something like this.

Identify Security Objectives -> Profile Application -> Decompose Application -> Identify Threats -> Identify Vulnerabilities for Threats -> Rank and ROAM Threats.

Of course, fix those vulnerabilities. :-).

Advice: Focus on fixing vulnerabilities and not threats.

• STRIDE method – For Threat Modeling
• DREAD method – For Threat Ranking
• (and there are so many other models)

STRIDE

If you are into OWASP ocean for web application security, the process (ever increasing) goes something like this:

References

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
• https://github.com/OWASP
• https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-mitigations
• https://learn.microsoft.com/en-us/azure/security/