- FREE COURSE - Learn Spring and Spring Boot in 5 DAYS
- FREE COURSE - AWS Certified Solutions Architect Associate - Getting Started
- FREE COURSE - Getting Started with DevOps and Cloud - Docker, Kubernetes, AWS and Azure
In this article, we explore the important non functional requirement called Security.
What you will learn
- What Is Security?
- Why is Security important?
- How do you improve Security of your system?
Free Courses - Learn in 10 Steps
- FREE 5 DAY CHALLENGE - Learn Spring and Spring Boot
- Learn Spring Boot in 10 Steps
- Learn Docker in 10 Steps
- Learn Kubernetes in 10 Steps
- Learn AWS in 10 Steps
Non Functional Requirements and Microservices
This is the second article in a series of articles on Non Functional Requirements:
- 1 - Microservices Architectures - Non Functional Requirements
- 2 - Security
- 3 - Web Application Security And OWASP - Top Ten Security Flaws
- 4 - Maintainability
- 5 - Scalability
- 6 - Performance
- 7 - Reusability
- 8 - Reliability
- 9 - Modularity
- 10 - Availability
- 11 - Portability
What Is Security?
Security in general means one or more of the following intentions:
- Protect the system from unintended use
- Protect the application service from denial-of-service attacks
- Protect the system from unauthorized access by external users
- Restrict the authorized users to access only those modules of the application that they are allowed to. Other modules must be protected from the user.
Security is all about:
- Authentication - Is it the right user?
- Authorization - Does the user have the rights to do an action?
Applying Security Principles
There are a few important principles that are the cornerstone for application security.
Assign Least Privileges
The architects, designers and developers must start the design of the system with security requirements in mind. Security must feature as an important project requirement from the initial stages itself. There has to be clear picture of the roles of various users, and the accesses that they need. The idea is to have as few accesses to each role as possible.
This applies not just to the application, but also to the infrastructure. This includes the application database, the servers where the system is deployed, and other similar things. The concept of minimized mapping of access to roles for each user, is equally relevant here.
Have Complete Mediation
How were King’s forts protected in medieval times? By having one entrance that everyone has to pass through and making sure that the entrance is extremely secure.
Do the same thing for securing your application.
For every request, apply a well-implemented security filter. Test the role and access of the user for each and every request.
Have Defence In Depth
This concept boils down to having multiple levels of security. You would need to have security built into your architecture at application, network, hardware and operating system levels.
Make sure that you validate every piece of data or information that comes into the system .
Sanitize all data that comes from external sources.
Have Economy Of Mechanism
This says that we need to keep the architecture of the system, simple. Simple systems are easier to protect.
Ensure Openness Of Design
Avoid trying to implement system security by making the design obscure. If that were the case, a hacker might identify a flaw and compromise the system.
This principle is the opposite of the misplaced idea of “Security Through Obscurity”.
The more open a design, the easier it is to identify and address security flaws.
Handling Application Security
There are three important aspects of managing security threats to an application.
The best approach is to prevent security incidents from happening by following the principles discussed early.
It is important to have mechanisms in place that detect security violations. When such a violation does happen, detecting it fairly early is worth its weight in gold.
After you detect a security violation, the step that follows is the reaction.
A major drawback when handling security violations is that more often than not, organizations are slow in both detecting, and reacting to them.
Make sure you have clear policies on how to react to security violations.
Best Practices In Application Security
Lets look at some of best practices in building secure systems.
Think Security From Day One
The business development, software development, QA and operations teams - all of them need to make security a high priority right from the initial stages. They need to be well educated about the various threats, and ways to prevent, detect and react to them as needed.
Be Aware Of OWASP
It is important that there is proper awareness of OWASP and their recommendations. They regularly release a “top 10” list about current security threats for applications, as well as tips on how to prevent them.
Use Analysis Tools
Use static analysis tools such as checkmarks regularly, to identify potential security vulnerabilities in the code.
Frequently have external security testers hack into your application software. This gives you a different perspective on security testing, and also find potential flaws earlier.
Avoid Outdated Standards And Frameworks
AN OWASP standard recommends that outdated software standards and frameworks having known vulnerabilities need to be eliminated from your architecture.
Only make use of an approved library/framework/platform that is certified by a security team.
Use the latest versions of these software.
Safeguard Your Infrastructure
Make sure proper protection mechanisms are in place to secure your app server, web server, OS and hardware.
Do check out our video on this:
In this article, we talked about what application security is all about. Essentially, security revolves round two things - authentication, and authorization.
We then looked at principles that help make your application more secure. These include assigning minimum privileges, having complete mediation, trusting nothing, have an economy of mechanism and keeping an open design. We then looked at several best practices when it comes to improving application security.