As a new website is developed, security goals often lose out to design aspirations. Learn how to keep security at the top of the priority list.
By
I recently worked with a company that was developing a website. At the kick-off meeting, the director in charge of the project stated, “This website has to look good, be easy and intuitive to use, and it has to be secure.”
Having reached the end of this project, I would say a more accurate statement would have been, “This website has to look great, be easy for me to use, and if we have time and it doesn’t compromise the first two aims, be secure.”
That may be a little harsh, but sadly, I’m sure most security pros who have been brought in to foster website security have had similar experiences. I am not questioning the dedication or commitment to the initial goals by any of the people involved in the project, but because humans are visual creatures, the influence and requirements of the graphic design team quickly became all-encompassing, with security pushed down the list of priorities.
In this tip about building a secure website, I will explore the often conflicting goals of the design staff and the security staff on a website development project, and provide advice for working through the tensions and delays that are bound to occur.
Design can overwhelm security
In the website project, the general attitude was that security was interfering and slowing up the “amazing creation” being conjured up by the graphic designers. Those tasked with coding the site were forced to spend most of their time writing JavaScript and testing to ensure they had produced the desired pixel-perfect effect.
Protestations about the lack of security control testing were quickly batted away by references to a variety of well-known sites that “don’t have that check, so why should we?” Even when we did get to test functionality — that the code did what it was supposed to do, and did it securely — the exercise was taken over by the design team. “Did the users think the banners at the top of the homepage changed too quickly, and was the Sign Up button obvious?” These types of questions regularly ate into what should have been time for functionality testing, producing a list of further design changes and little in the way of back-end stress testing.
So how do those tasked with ensuring a website is built securely overcome these problems and elevate security on the priority list?
The first thing to do is to accept that, despite any reassurances you may be given, as the launch date approaches, security concerns will quickly fall down the To Do list, while look-and-feel issues and usability will dominate any meetings and requests for additional resources.
Take ownership of business functions
The best course of action is to plan in advance. Early in the project, you need to identify processes that have the most potential to introduce vulnerabilities, and take strong ownership of them. My recommendation is to work flat out with the code developers to get the main business logic implemented.
Here is an example of how implementing business logic early in the project can give you time to test security. If a site is intended to offer a subscription service to a weekly online magazine, start by building the registration, payment, login, download and account management pages as soon as possible. This will quickly uncover any issues with the business model behind the project; no matter how well planned, the business model will have flaws that will not be apparent until the site starts to come to life. No, the webpages won’t look pretty, but being able to run some simple user tests at an early stage is important. This will prevent the situation I had where the actual business model and a good portion of the back-end code were changed after a user testing session, just three weeks before the site went live.
Separate the data from the view
In order for the project to move forward without the security and design teams delaying each other, use a Model-View-Controller (MVC) framework that splits application development into three distinct spheres, each handling a discrete set of tasks: the model represents the data, the view displays the model as a webpage, and the controller handles user actions and changes to the model or view.
Data returned by the model has no formatting, so it is display-neutral. This means model code only needs to be written and tested once, and the graphic design team can concentrate on how the data is displayed – the view. Meanwhile the coders and the security staff can work on the controller, which handles the input events when the user interacts with the user interface. Once a component within MVC has been tested and security has been checked, the component can be reused repeatedly. This approach enables each team to work with each other, while not holding each other up unnecessarily.
In my previous article, PHP MVC framework tutorial, I said that using an MVC framework may be overkill for a small project. But I now think that it may be the only way to ensure security and sound coding practices receive the same attention as other aspects of building a website.
Get a two-week cushion
My final piece of advice is that you push for the project completion date to be at least two weeks before the proposed launch date. The project will overrun the completion date, but if you build in a gap before launch, then you will still have some time to carry out stress tests, code reviews and corrections.
In an ideal situation, we would all have enough budget and time so many of the problems I’ve discussed won’t be an issue; the site build would follow Microsoft’s SDL and the code behind each “submit” button would have been rigorously tested. Theory is fine, but achieving security in the face of real-world pressures is a stressful challenge, but one that can be achieved with proper planning and perseverance. In the business world, new websites rarely have generous budgets and they never have the luxury of a lengthy time-to-market cycle. This means you have to adjust the way you tackle the issue of Web application security to ensure it remains an important and achievable project deliverable.
Culled from ComputerWeek
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Cobb serves as SearchSecurity.co.UK’s expert for application and platform security topics.
