In the design phase, many critical and strategic decisions of software security architecture are taken to ensure the desired features, system quality and, of course, security.

We started our conversations about software security talking about concepts that are considered the Security Core. Today we will delve a little more on the subject, addressing the second part of our Security Concepts table that just talks about the principles of software design.

Software design principles define effective practices that are applicable mainly for software security decisions in architecture level and are recommended regardless of platform or language of the software being used.
 Post_01082016_Tabela_4
Least Privilege
This principle restricts how the privileges are granted and is based on the idea that, to a person or process, is given only the minimum access rights (privileges) that is necessary for the person or process to complete a given operation. The granting of permissions beyond the scope of the duties required of an action may allow to obtain or change information in undesirable ways.
Separation of Duties
Compartmentalize software security into separate components that require multiple access checks can inhibit an attack and potentially prevent an attacker to take an entire system. Also known as the principle of compartmentalization, this security principle states that the successful completion of a single task is dependent on two or more conditions that must be met, and only one of the conditions will be insufficient in the execution of the task itself.
Defense in Depth
The principle of defense in depth is based on the creation of security mechanisms in layers to increase system security as a whole. If an attack causes a security mechanism fail, other mechanisms may also provide the security needed to protect the system as a whole.
Fail Secure
Error handling with security is a key aspect of secure encryption. This is a security principle that aims to maintain confidentiality, integrity and availability, rapid recovery of software security under the aspects of treatment or implementation of failures. In general, the safety mechanism must be designed so that a failure will follow the same scheduled execution path as not to allow an operation, for example. An exception cannot allow that implemented security layers are exceeded.
Economy of Mechanisms
Keep the design as simple as possible. This well-known principle applies to any aspect of a system, but with emphasis on the protection mechanisms: design errors and implementation that result in unwanted access paths will not be noticed during normal use, since it generally does not include attempts to exert inadequate access roads. The probability of a greater number of vulnerabilities increases the complexity of the software security architecture project and code.
Complete Mediation
This security principle ensures that the authority is not undermined in subsequent requests for an object by a person or process, through the authorization check (rights and privileges) on each request for this object. Whenever a person or process tries to read an object, the system must mediate the action. First, it determines whether the person or process can read the object. If so, it provides the means of that reading to occur. If the person/process tries to read the object again, the system should return to verify that the person/process can still read the object. Most systems do not do the second check. They keep the results of the first check in cache and base the second access on the cached results.
Open Design
This security principle states that the project implementation details must be independent of the project itself. When the software is designed using the concept of open design, the review of the project itself will not result in harming the security software. Security through obscurity is a weak security control, and almost always fails when it is the only control. This does not mean that keeping secrets is a bad idea, it simply means that security systems should not rely only on keeping details hidden. Security must rely on many other factors, including reasonable policy password, defense in depth, business transaction limits, solid network architecture and fraud and audit controls.
Least Common Mechanisms
Avoid having multiple classes that share mechanisms to grant access to a resource. Each shared mechanism (especially one that involves shared variables) is a potential access route to information and should be designed very carefully to make sure it will not unintentionally compromise security. Sensitive information can potentially be shared between them through a single mechanism. A different mechanism (or instantiation of a mechanism) for each subject or class of individuals can provide access control flexibility between multiple users and prevent possible security breaches that would occur if only a mechanism was implemented.
Psychological Acceptability
A security principle that aims to maximize the use and adoption of security functionality in the software, ensuring that it is easy to use and at the same time transparent to the user. Ease of use and transparency are essential requirements for the security principle to be effective. If the security mechanisms hamper usability and accessibility of resources, users can choose to disable those mechanisms. In this way, security mechanisms should be friendly to facilitate their use and understanding in a software security application.
Weakest Link
Security professionals point out that security is a chain, and a chain is only as strong as its weakest link, a software security system is only as secure as its weakest component. Hackers will attack the weakest parts of your system, because they are easier to be broken. Often the weakest part of your system will be administrators, users or tech support people who are victims of social engineering. This security principle states that the resilience of your software against hacking attempts will depend greatly on your protection of its weakest components: code, service, interface or people.
Levering Existing Components
This is a security principle that focuses on ensuring that the attack surface is not extended and that there are no new vulnerabilities introduced by reusing software security components, code snippets and features. Be very careful when downloading ready classes and include them in your system. By doing so without proper care, you may be introducing a vulnerability that will charge you a high price in the future.
Draw a software architecture based on safety principles and their problems will be solved. It is a lie. Do not believe it. That is just the beginning. Most importantly is that you and your company adopt a safety culture, build solid foundations upon these concepts and complete a gradual, firm and systemic implementation of policies, methodologies and secure code development standards.
You and your team should develop codes from the perspective of a possible attacker. How and where could he have access to your information? What information would he have more interest in? Once successfully attacked, how would you correct quickly the failure?
As the recognition of safety as a fundamental dimension of high quality development has grown, the understanding and ability to create secure software has become a high and very common expectation of the market as a whole. And in times of crisis, it is prudent and strongly recommended to be in line with market expectations.

You might also like…

Tips on facilitators for developers – Part II

Hello! On the latest post i’ve shown some hints on facilitators for developers. On today’s post ...

What are RAD, Framework and IDE – concepts and applicability

What are RAD, Frameworks and IDE? Understand the difference and how we can use them to optimize the ...

Trends for web development in 2017

In this post you will see some Web Design, Digital Media and Development trends for 2017. Immers...

Comment this post

Get new posts, resources, offers and more each week.