Introduction
According to the 2008 Data Breach Study published by the Verizon Business Risk Team, the most common type of attacks by the cyber criminals targeted applications and software. The study further outlines that 73% of all such attacks were from the external sources taking advantage of existing vulnerabilities in those applications and software. Imagine you were the programmer of one of these applications; would you like to share your emotions about how honorable you will be feeling being owner of these “Compromised” applications, because the applications which were the jewel assets of you and your organization are now nothing but "hacked Websites" and "compromised applications".
Studies further show around 57% of the vulnerabilities are caused by the coding and design errors. Stating bitter facts further, on an average 8 vulnerabilities in every application are due to coding and design errors. Research by Gartner Group and Symantec says, close to 90% of software attacks were aimed at the application layer.
Sirens are echoing, lights are flashing all over and the message is loud and clear that applications are the target and it would not be wrong to say that it’s state of war for programmers, remember if you fail to plan, you plan to fail.
It is a serious matter of concern, because if it continues; then software developers will lose the reputation, organizations will withdraw their confidence on developers, the average market salaries might start to contract because every breach not only results in the loss of organizational reputation but is an extra cost to an organization as well. According to the studies, the estimated cost of such breaches is around $180 billion per year.
The Point of Interest
Let’s not discuss these terrifying figures further, peel the onion and come to the point!!
Folks our old school of thought is “build it first and fix it later’. Security issues are often the last issue that gets addressed in either development or testing, and fixing a security issue is not even worth a mention when budgets are tight and a project overruns.
A cure to this malady is to begin securing from the beginning which could best be understood by an analogy “If security were the electrical wires, then it is more difficult to put the wiring in after the house is built.”
It means that application security is more susceptible than ever in today’s dynamic application development landscape. In fact, the root cause of many application security vulnerabilities lies in the application source code, so is secure coding an answer to all these problems? The answer is “NO", secure coding addresses the part of the problem, many of the breaches are not only the result of coding errors but because of the bad design, that highlights the fact that security requirements should be considered at every stage of the software development life cycle.
What's the Game Plan?
Application development is a fine balance between functional requirements and business needs; a fine balance between resource and deadlines; but now it should be a fine balance between security and risk as well. Security is now one of the attributes of software like usability, performance, reliability, scalability and is a candidate for the same respect which other attributes deserve.
"Security is just another attribute of software like usability,
performance, reliability and scalability. The idea of incorporating security
into the SDLC begins with the evaluating the relative importance of this
attribute and then going on to incorporating controls in line with that"
- Tallah Mir Sr. Program Manager - Microsoft
Acknowledging these facts, embedding SDLC phases with security considerations is the right approach.
Requirements
How could you secure an application if you do not know what you have built? Do you know your application?
A good starting point is the technical and requirements specifications. Understanding the coding that was used to build the application meets one of the four security principals “to know your application”. During the requirements specifications stage, ask the following questions:
- What are the technology security considerations?
- Are there any business model security considerations?
- What are the main threats to the system?
Architecture / Design
No one designs things for the wrong reasons. Remember two heads are better than one. Involve the Security Risk Team right from the day first. Think how can security requirements be designed in? What could go wrong? What are the main threats to the design? Consider the following design principles:
| Principle | Meaning | Example |
| Economy Of Mechanism | Keeping the Design simple and less complex | Modular Code, Centralized Services |
| Fail-Safe Defaults | Access Denied by Default and Granted Explicitly | Denied Transaction |
| Complete mediation or Mandatory Access Control | Checking permission each time subject requests access to objects | Credentials not cached |
| Open design | Design is not the Secret | Popular Cryptographic algorithms |
| Separation of Privilege | More than one condition is required to complete the task | Split Keys, Compartmentalized Functions |
| Least privilege or Discretionary Access Control | Rights are Minimum and users granted explicitly | Non admin accounts, need to know basis |
| Least common mechanisms | Common Mechanism to more than one user / Process / role is not shared | Role based security |
| Physiological acceptability | Security Mechanism should be communicated to end user for ease of use and acceptance | Help dialogues, appealing icons |
Coding
During the coding, make sure that code is robust and secure. Adopt the most pessimistic approach of "TRUST NOTHING" or “DEFENSE IN DEPTH”. For example, while taking input don’t rely on the content, don’t assume users are entering correct information. Remember the golden rule "When in doubt, check it out!!”. Identify what the main threats to the code are?
Ascertain with the security features of any programming language before taking a decision to code in it. Interestingly, with each programming language there is a tradeoff between efficiency and security. C and C++ provide efficiency and speed, though the code pays little attention to security issues, knowing what could go wrong with coding is important in that they affect security issues. Remember:
"No language can prevent insecure code, although there are language features which could aid or hinder a security-conscious developer."
-Chris Shiflett
Be careful while choosing Development Methodologies, when adopting security in every phase; what kind of methodology should we use, waterfall, iterative, spiral, extreme or agile. Are these methodologies flexible enough to incorporate your security considerations in each phase.
In a nutshell, you can’t create secure applications and software with rules alone, the principle of secure application and software development are applied across development methodologies and across programming languages as well.
Testing
There are several types and levels of testing, which I won't write about extensively. Suffice to say, augment UAT with SAT (Security Acceptance Testing). UAT where signals we are all GOOD to go, SAT testifies that we are all SAFE to go.
Bottom Line: Keep an Eye on the Big Bad Wolf
"In the 80's we wired the world with cables and in the
90's we wired the world with the computer networks. Today we are wiring the
world with the application (softwares).... Having a skilled professional
capable of designing, developing and deploying secure software is not critical
to this evolving world" - Mark Curphey, Director & Project Unit Manager Microsoft
and Founder of OWASP (Open Web Application Security Project)
It is important to remember that nothing is permanent except change itself and if you won’t change, it's likely that you will not survive much longer!!!!
References
