Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
We have previously discussed the importance of integrating Security concepts and practices during the Software Development Life Cycle and the requirements phase. We have also shown you studies that confirm how important is to develop software and applications that include Security from the very first phase of the SDLC process.
In order to make it easier for us to write and for you to read our stories about the SSDLC, we have chosen to follow the well known Waterfall Model. Today we will discuss the Secure Software Development Life Cycle Design Phase.
The Design phase is commonly defined as the set of actions that will translate all of the business and user requirements from their formal and verbose structure into architectural vectors that can be coded (or implemented) into executable pieces of software (ref. Mano Paul, Official (ISC)2 Guide to the CSSLP).
The above definition is, of course, quite generic but it sums up the concept of Software Design well enough. It’s also a good starting point for the discussion that follows.
The implementation of Security in the Design phase typically requires the attention of knowledgeable actors. In a perfect world, a software team would employ security experts to support software architects as they design a piece of secure software.
The best possible scenario is to involve architects who master secure Design principles and techniques. They should be aware of the whole theory that defines the Secure SDLC. This is why It is highly suggested that these professionals consider enforcing their awareness with focused trainings about security best practices.
The majority of vulnerabilities discovered in software are caused by bad design, incorrect technological decisions or because little attention has been given towards security during the Design phase.
Semantic flows and business logic flows are typically hard to fix once a software has been coded and they all originate from decisions taken without considering the role of security during the Design phase. Statistically - and based on our own experience - more than 90% of all complex and expensive software refactorings are due to the lack of attention or due to the execution of a rushed Design phase.
Unfortunately, all of the above is often caused by the absence of awareness for the matters of Security when it comes to the Design phase within software companies.
By looking at the concept of the Iron Triangle we may be able to find a justification for the lack of security during the Design phase.
A quality software project, from the perspective of the manufacturer or the commissioner, should be seen as a combination of the budget, resources and the time spent building it (schedule) before, eventually, a product is able to generate a ROI.
Manufacturers tend to reduce all three of the aforementioned factors, resulting in a dramatic overhead on the developers and architects. When security is a constraint, manufacturers must immediately address the need for a higher budget, more time and more resources.
In this case, it is not unusual to avoid considering security during the Software Development Life Cycle or to think about it later during the following phases or as an activity outside of the SDLC domain.
Unfortunately, it has been demonstrated that this approach is actually more expensive, resulting in a dramatic waste of all aspects of the Iron Triangle.
In fact, Security is often seen as an “afterthought” and as a consequence, the cost of fixing security issues in a piece of live software can be higher than the cost of implementing secure design techniques before the software began to be coded.
The Iron Triangle demonstrates how security, especially when taken into account during the testing phase - or as an extreme example, when a breach has already occurred with consequences - has a relevant impact not only on the company's reputation but also in terms of money spent to allow security remediation, which always involve resources and time.
A securely Designed software can ultimately minimise the budget and maximise the ROI, protecting the reputation of a software vendor and limiting the budget over time.
A piece of software that is correctly and securely designed is also of a high quality. In a nutshell, injecting Security within the Design phase means addressing design decisions that take into account the perspective of an attacker that is trying to breach weaknesses and compromise the confidentiality, the integrity and other important security aspects of your software. Let’s take a look at some of these aspects a bit more closely.
Security and Confidentiality
Protecting confidential data that is stored, processed or transmitted by your application requires a deep knowledge of Cryptography techniques.
Malicious individuals attempting to breach the confidentiality aspects of your software are experts in the field of Cryptanalysis. Designing strong confidentiality protection should not be limited to the typical decisions of encrypting data when it is stored but the real intent is to make sure that the full data set is actually identified (i.e. via implementing a Data Access Control Matrix). Furthermore, data flows have to be clearly defined so that designers are able to intervene differently according to the different types of data and the different stages of their lifecycle.
Secure Integrity Design
The Integrity Design should not guarantee unwanted or unauthorised modification of your software and make sure that its "states", or the data it handles, are never allowed. When asked about Integrity Design, a security class student should immediately reply using a sentence that contains, correctly, the word "Hashing".
"One way overt cryptography functions" (aka hashing) are a must have when dealing with specific Integrity related matters (i.e. password storage). However, it is important to address the fact that Integrity has a wider spectrum of applicability and a good security designer must consider other aspects too. A good example might be the presence of relational databases.,
Normalization techniques applied to RDBMS (Relational Database Management System) are enforced by properly Designed referential integrity constraints. These are actually injecting Integrity in databases, making sure that the phenomenon of orphan records is either limited or eliminated completely.
Additionally, the Secure Design phase, when dealing with Integrity matters, might include discussions and actions concerning deadlock protections (via resource locking) and code signing techniques, when required by the specific nature of a software.
The "A’s" in the Design phase
Availability, Authentication, Authorization, Accounting and Auditing are all important aspects of a piece of software and are unfortunately a great source of inspiration for attackers, when "insecurely designed".
For example, Denial of Service attacks are “business as usual” for hackers and in many scenarios, they are able to activate a disastrous chain of effects, breaching the first “A” in the list, continuing with the others, with the result of compromising the so-called "crown jewels" (i.e. confidential data).
All we have said in this articlee shall be considered as a non complete set of secure Design principles, processes and practices are well documented and bound to specific aspects of a piece of software.
Security is a key factor (and it always should be!), and in the context of complex software architectures, architects should focus their attention to the most famous Design process for secure software, Threat Modeling. This process can be used to precisely map security vulnerabilities and apply security countermeasures to avoid the evolution of vulnerabilities into threats to assets.
What are the advantages of a securely designed piece of software?
Here at Advantio we understand that your development team may not be able to promote security best practices and concepts during your Software Design phase, which is why we offer several different methods for making your software more secure.
We can review your software's code, evaluate the status of your Software Development Lifecycle to ensure that your team is taking the right steps towards secure software and we can also train your team so that they have a better understanding of SSDLC concepts and practices.
I am the CTO and Senior QSA at Advantio.
As the leader of PCI DSS Audits on Compliance since 2010, I have executed close to a hundred (and counting) assessments across Europe, Asia, South Africa and North America.
I am particularly passionate about the secure software development lifecycle, cloud services security, risk management from both the technological and the design perspective, and ultimately innovation in the security domain.
At Advantio, I am also part of the ZeroRisk team. Our vision is to make security and compliance simpler for our users.