Product Security — Dev Sec Tips — 2
In this series of Dev Sec Tips I would go through my notes on basic security design principles which can be considered by Dev before designing and coding their features in the app , you may have read it elsewhere as a security professional thought of documenting over here for easy reference if you are an security advocate for the app you build.
Subject referred over here is User of an Application or Feature
Trust Subject but Verify :
If a subject is system trying to connect to another system verify the connection by a method of mutual authentication
If a subject is a User trying to access a feature in application verify the user by a method of identifying the user and then authenticating the user with username / password , two factor authentication etc
Validate the Inputs by Subject :
If a subject is a User providing the Inputs to a feature in the app verify that the inputs provided by the user is as per agreed list of secure safe inputs for example to prevent any Injection flaws in the application
Principle of Least Privilege :
Subject is given enough authorization required to accomplish an individual operation task directly or indirectly on OS , Application , Database for example this principle would apply to OS | Application | DB to prevent any privilege escalation attacks , any injection attacks etc
Defense In Depth :
System or Application should have layered approach for security so that if one security control is compromised by the adversary the impact is restricted to that object of attack is not escalated using further attack methods a good example would be in SQL Injection attack if for some reason User Inputs from a Subject to an application are not sufficiently validated to result in execution of crafted sql injection strings in control context then the principle of least privilege can be an additional security layer of defense to contain the impact of the attack to the application.
Separation of Duties :
Segregating access to functionality on the application so that one subject role does not hold all the rights to your application. For example firewall management application may have user roles like security implementer and security approver so that the security implementer implementing the firewall rules on his network firewalls is not the security approver as well to those rule changes employed on the firewall.
Keep Things Simple:
Humans are considered the weakest security link to an application or system so implement enough security controls around the features in application in a user friendly way so that users are not frustrated to evade those security controls implemented and still able to use that feature .
Logging of Events:
Prevention is one way of achieving good security for your application but Detection also plays an important role in Security to make you aware if something bad happened to your application and to the extent it happened and when it happened. All these capabilities can be achieved by logging of events.
For example : NonRepudiation = Who , When and What of subject performed specific actions
Fail Secure :
If a system or application falls into an error condition due to Denial of Service Attack or other Fuzzing attack on the system or application do not reveal too much information to the attacker in error messages or fail open (without authentication) the system or application to the attacker as the system or application was not able to understand the attacker packets ; securely fail the system or application .
Build Security In App :
Confidential , Integrity and Availability also known as Security Triad , CIA Triad should be built in the application rather than asking the subject of the application to enable security by bolting on any external security mechanism for example in brief for Confidentiality — Use of Transport Layer Security , Integrity — Use of Crypto primitives like SHA2 ,SHA3 , Availability — Use of Rate Limiting
Would like to hear your feedback on @santokri1