Click here to Skip to main content
Click here to Skip to main content

Programmers’ War of Survival

By , 7 Jun 2010
Rate this:
Please Sign up or sign in to vote.

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:

  1. What are the technology security considerations?
  2. Are there any business model security considerations?
  3. 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

License

This article, along with any associated source code and files, is licensed under The GNU General Public License (GPLv3)

About the Author

Altaf Al-Amin

United Arab Emirates United Arab Emirates
Altaf Al-Amin Najvani
Project Manager
Commercial Bank Of Dubai
 

Qualifications:
BS - Computer Science
Masters In Project Management
Masters In Business Administration
 
Certifications:
CISA - Certified Information Systems Auditor
ITIL (Foundation)
Microsoft Certified Technology Specialist (SQL Server 2005)
Microsoft Certified Technology Specialist (Web Applications)
Microsoft Certified Application Developer (.NET)
Microsoft Certified Solution Developer (.NET)

Comments and Discussions

 
GeneralInteresting.. a few questions though. PinmemberZakPatat9-Jun-10 11:35 
GeneralRe: Interesting.. a few questions though. PinmemberAltaf Al-Amin9-Jun-10 20:24 
GeneralRe: Interesting.. a few questions though. PinmemberZakPatat10-Jun-10 20:37 
You are correct, a lot of developers do live in their own 'box' where what they believe is correct is, indeed, correct, even if it is not. I agree entirely with the notion that open standards need to be followed, and I approve of your effort to point out some of these standards, it is, sadly, sorely needed.
 
My personal problems are more related to 'internal standards' for security that were created before most open standards. Mixing those two is a nightmare to organize and manage but we can't just throw a switch and have hundreds of applications follow different standards. The vast majority of these applications (ranging from the 70's to the present in age, we still have some REALLY old mainframes here and there) 'talk' to their closest data center (all of which we own), which in turn propagates the information to the other data centers. Implementing today's (open) standards into applications that are 30, 40 years old, is simply not an option, in fact, we don't touch these applications at all (if we can avoid it), considering that they work and that due to their age, we probably lack the knowledge to fix issues with them (there was a time when the corporation did not document everything, sadly).
 
The only way of updating software under those circumstances is to phase out the old legacy system entirely. That means developing new software for new servers. Depending on the size of the application, the amount of data, the required transaction figures, etc this could be anything from a simple Windows server to a top of the line database oriented server in the realm of AS/400's and such. The larger non-Windows systems can be tough to develop today's standards into, since they usually come with limitations that an all-purpose server system like Windows Server does not have.
 
This is a slow process, my resources are limited and I cannot simply hire 200 extra developers Smile | :) . As a counter-measure to the security issues that potentially exist on a software level, we own the data centers, from building to all the equipment and personnel in it. We also own all the data lines that run between the data centers as well as the data lines that run to our facilities. Internet traffic does go through these data centers but are kept 100% separate from our internal communications. The only weak link there is the computers attached to both the internet and the internal network(s), so there are many layers of (hardware-based) security applied there. The cost is immense, but this is a requirement due to the nature of things we produce for our clients.
 
This extends further than just the hardware and software, we also depend on our employees to maintain security by simply following the rules set regarding classified information.
 
I don't think 100% security is obtainable, no matter what you do to maintain secure, on any level, from simple pen & paper to software to people talking.
 
On the 'end-user vs development' side of things, I do agree that end-users need to be involved, they are the ones who will eventually use the software. However, this involvement ends when the actual coding of the software starts. At that point the functional and technical designs of the software are set in stone until the first version is completed, and the end-users have no real reason to be involved with the actual code. Once the code is done for the first version (which could be a prototype, depending on the project), and the internal testers (technical testing) have done their jobs (and subsequently the developers have fixed whatever they found), then the end-users, or a selection thereof, become involved again, this time to perform functional testing, usually aided by the technical testers as well as people who observe the usage of the software by the end-user, the software itself also collects data regarding the 'how do they use the software' bit. This information is used to tweak the software for functional efficiency.
 
There is another testing step after that, but security rules prohibit me from discussing it, in any case, it doesn't add much to the above processes since it doesn't involve end-users directly.
 
While the above isn't exactly 'agile', it does involve the end-user quite a bit, in fact, they pretty much design the software, on paper. We deal with the implementation of not only their wishes but also how they wish to actually do their work with new software (to a degree of course, trying to find that fine line in the middle and all that). Once we're done with that side of things, they get to use it outside of production, comment on things (the bit where we can tell them that it was their idea in the first place, so don't blame us Cool | :cool: ) and come up with ways to make things more efficient (aside from our other efforts in that area). A 'little' tweaking later and we have the software in production and it is exactly what they want, done our way. They never see/hear/notice any security measures within the software apart from 'log in' and 'log out', they are, however, free to bring up security related ideas and comments during design and functional testing, after all, they are the ones who know how to do their job, not us. Nor is it up to us to dictate to them how they should do their job (albeit that there are situations where that is unavoidable, but those are rare).
 
In the end, the software we produce for our divisions, is straight forward and to the point. There is no additional 'fluff' besides what they need to do their job. Since we do code modular, any additional functionality is easily implemented, and will be implemented as long as it is not 'fluff'. As little distraction as possible within the software is one of our top 'rules' to development. Most of our newer (three years old to present) software can crash completely, including servers, etc, all the end-user notices is a slightly longer pause when a transaction generated, this pause being caused by one of a set of fail-overs, usually switching to other servers that have mirrored the databases, even if that means sending the transaction half-way across the world. The lack of client software (everything is browser based) helps with this of course, crashes on the client-side are either the browser, a bug in our software (extremely rare, plenty of bugs, but nothing that would crash entire systems), or the computer being used by the end-user. For any other situation, we have some sort of fail-over.
 
You may have noticed that I bring forth a lot of topics that seem to have little to do with 'security', however, most of the above involves security in one way or the other, in the 'fail-over situation', it is data security, but more importantly, allowing the end-user to continue working no matter the situation (you can't catch all situations, but we have most covered). While our software works decentralized on the surface, behind that is a highly centralized system solely intended to enhance security, attempt to keep the users working in almost any situation and make sure that at least three mirrors (at max, there are twelve, depending on the importance of the data) exist of whatever data they require. We don't back up data anymore for example, instead the most important data is real-time mirrored onto arrays of solid state storage that is not located at our data centers but rather at individual facilities, it is possible (and with extremely important data, highly probable) that data from a US based facility is stored on solid state storage at one (or more) of our facilities in Europe.
 
The real beauty lies in the fact that the end-user doesn't need to know this (albeit that it is no secret, so if they're interested, we'll gladly explain), they also don't really notice it even if problems occur (apart, of course, from severe problems occurring, for example total failure of power on their side will turn off their systems if the facility does not have a UPS system powerful enough to keep everything going (most don't, but some do)).
 
In the end, our job has become easier, the software is as secure as it can be, the backbone is as secure as it can be and the end-user never really notices anything beyond a bit of lag. Nothing is 100% secure, but you can definitely attempt to get as secure as possible, one way to do so is what we do, creating security that secures other security next to following simple standards during development. On top of that, all data is transmitted with a high bit encryption algorithm.
 
Keep spreading the word my friend, way too much insecure software out there. I can tell you stories of linking our internal networks to suppliers and the nightmares that causes on a security level that would scare your average security expert enough to change jobs.
GeneralReserving grade... PinmemberRay Cassick6-Jun-10 8:30 
GeneralRe: Reserving grade... PinmemberAltaf Al-Amin6-Jun-10 8:57 
GeneralRe: Reserving grade... PinmemberRay Cassick6-Jun-10 9:24 
GeneralRe: Reserving grade... PinmemberAltaf Al-Amin7-Jun-10 19:10 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140415.2 | Last Updated 8 Jun 2010
Article Copyright 2010 by Altaf Al-Amin
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid