Is your Application Development Secure?

0 comments

Posted on 27th July 2016 by Tolga in Security

The original article was published on 02 June 2016 at 21st Century IT
Link: http://www.21stcenturyit.de/is-your-application-development-secure/

As companies more and more rely on more specific business applications in today’s fast paced business environment, the software development facilities serving the company have become a strategic partner. A partner that has become overwhelmingly occupied with projects so detailed and complex that it was just necessary to split up the project phases that developers can concentrate on their core duties… the code itself. So far so good, you have it all; your Project Management Office to coordinate the efforts and assign resources, Business Analysts to understand what the business wants, System Engineers to provide you with the infrastructure and keep your code running, the Testing Team that will push the application to its limit and most important your Developers, they will in the end provide your product… which essentially means that your kitchen is ready to serve good food!

However, most of you know that in order to get a Michelin star, it takes more than just to serve good food. The whole package requires to be perfect!

So what did we miss in between? Ah, right… Security! Well some of you might think at this moment that you already have an IT Security or Information Security department that is gracefully handling these issues.

But this is where the problem starts off with custom applications and their infrastructure. It’s almost like building a car, you develop the car with the security measures and then test it; you don’t just build the car and then send it off for a crash test then to later on add the safety measures.

What to do right now? Well there are a variety of frameworks to choose from at this moment, however I’ll be giving the essentials.

1.Push Awareness
Unless somebody doesn’t have an idea on something, it is impossible to tell them that it is important. So in order to get them all sparked up on the issue put them in training, but don’t go through with the PPT slides, give them illustrative examples, do something, exploit their code and tell them why it is like this. In order to this you will need people that have a good knowledge of code and security, namely an Application Security pro.

2. Have the Security SME (Subject Matter Expert) always included in the Design Phase
Starting off from scratch with the IT Architect? Now is a good time to include the Security Architecture into the plan, have the Security SME with you, to guide you on the essentials, such as which controls you should have implemented into your input fields, how you should authenticate your webservice, where you should use secure channels for communication, what hash standard to use and how, why the database shouldn’t have a user within a DBO profile… all this and beyond should be talked through with the Security SME. This will certainly make life easier and avoid later conflicts, or major changes due to a vulnerability.

3. Prepare and Distribute Standards Guideline
“Verba volant, scripta manent”… the Roman Senate knew then, we should today. It’s always a great idea to set up certain written guidelines and prepare standards for coders. The best part is, you wouldn’t need to go all Columbus and re-discover America… Have a look at already well established Open Projects and Standards, digest these into your environment. Have them reviewed by your programmers and see how applicable they are.

4. Go for Peer Review
Even though automated tools have come a long way and give you suggestions on what to change, still nothing can beat the eye of a seasoned developer. You should assure that each piece of code that has been written, has been peer reviewed and approved by a mentoring coder.

5. Do Dynamic and Static Analysis
If you have come this far, still to be on the safe side dynamic and static analysis testing should be done in order to assure that everything is working smoothly. Also this can be considered as a checkpoint for further suggestions within your guidelines.

6. Don’t forget about the Infrastructure
Even though Application Security seems to be all about Application Security, “thou shalt not neglect thy Infrastructure”. In the end the infrastructure will be running and hosting the Application, the harmony between both should never be neglected and appropriate hardening should be done in conjunction with a penetration test to the infrastructure.

7. Consider Evergreening
Wait! Now you might ask yourself why you should consider Evergreening for your in-house software, wasn’t this supposed to be the case for commercial applications where the vendor provides version upgrades? Yes, and no… depending on the case you will be using extensions within in your applications, for example most web applications use JavaScript libraries from open source projects, and yes from time to time they have their own flaws as well… so considering this, keep up with the extension household.
So on a high level, it would simply make life easier for everyone within the Software Development Lifecycle. And as I’ve pointed out before, in nowadays environment it is crucial to have these steps embedded in the development lifecycle. Also, “keeping up with the Joneses” is paramount in security, just because you are following these steps doesn’t mean that you have achieved complete maturity, evolving with the threats, updating and keeping up with step 1 and continuously raising awareness is a must.
Who knows maybe in the near future we will have IDE’s that will instantly point out a security flaw, and suggest you to not embed the password into your DLL. But till then we will have to work with an embedded lifecycle.

No comments yet.

Leave a comment