|Adding application security : SC Magazine : Blog : Home|
First Published: SC Magazine
Having been focused upon the (in)security of web-based applications for over 6 years and working closely with my clients on securing them, it is refreshing to see that a second wave of businesses are finally turning their attention and allocating resources to deal with perhaps their largest external security threat. Technology trail-blazing organisations such as large financial institutes have been working to secure their Internet accessible applications for several years, but the second-tier “technology following” organisations have been slow to follow. Fortunately this is now changing.
With headline’s reporting various phishing and account hijacking attacks that potentially affect their own customer base, these organisations have begun to realise that they are once again behind the technology curve and are calling out for assistance. In many cases these organisations are initially seeking advice on where to begin the process of securing their web-based applications. Depending upon their internal development processes and security awareness, there are many areas in which security specialists can leap to their aid and begin the process of working with the client in securing their applications.
While it sounds rather simplistic, there are three key areas in which my colleagues or myself regularly get involved when called to secure critical business applications; the beginning, the middle, or the end. Starting in reverse order, “the end” refers to applications that are currently live or about to be deployed within a live environment. Here the consultants tend to utilise a Grey-box testing strategy to identify probable security weak points from a hackers perspective and, once a weakness is discovered, work closely with the development team to discover whether it is exploitable and what remediation steps need to be undertaken. Quite often “user-level” testing is carried out in conjunction with classic penetration testing processes and onsite infrastructure security assessments. The disadvantages of trying to secure applications at the end of the development cycle is that instant fixes tend to be patched on – delaying deployment and being more complex to implement robustly.
For many organisations that either outsource the development of their applications, or where their live applications are under consistent change, my consultants help implement security features and processes at the “middle” stages. Here the consultants work closely with the clients security or QA and testing teams to secure code as it gets applied to the live systems. This typically requires high volumes of native code review and identification of poor coding practices, followed by piecemeal instruction on secure coding practices.
As many organisations already enable their QA or testing teams with the power of veto over code changes to the live systems, they are ideally placed to police the security of new application changes. Unfortunately many of these teams are not particularly security aware (at least from a technical level), and must be trained up to identify insecure coding practices and increase their security skills in order to provide guidance to wayward developers.
My clients have found it extremely valuable to add a couple of security consultants to the team initially (ideally to implement secure practices immediately) and to participate in knowledge transfer exercises with their current team. After a month or two, the QA and Testing team will have developed the necessary processes and procedures for validating new code as well as understand the core aspects of a secure application.
The final area where security consultants can get involved is “the beginning”. This I define as everything that happens before real code development begins. Consequently the types of services I have found valuable to my clients at this early stage focus around specialist technical workshops.
Technical workshops that bring together the clients core development specialists and technical authorities, along with one or two external security specialists, enables frank and open discussions of key aspects of the application currently under development. Topics under discussion revolve around business requirements for the application, how these can be met through code development technologies, and what these decisions mean from a security context.
For instance, the application may require users to authenticate using web-based forms. The development team covers how they initially propose to implement this, while the security consultants make them aware of how attacks such as automated account brute-forcing attacks are conducted and provide guidance on how their code should respond to things such as failed logins and initial password allocations to users.
The end result is that not only does the application become more secure, but the developers themselves learn more about the threats their application is likely to encounter and how to respond. While some may argue that the developers could pick up much of this information from traditional “ethical hacking” training courses, I have found that the focused approach of a workshop provides greater opportunities for security dialogue. Instead of being “talked to” as in a training course, the free flowing form of the workshop allows all members to participate in the security design and to better grasp the security principles that will be applied to the application.
For the applications security itself, having workshops early on in the development process ensures that security is built in to the core. This not only makes the application more secure, but also makes it much easier to code – both during the development process and post deployment. There is of course another benefit – particularly for security departments. By ensuring that the security consultancy occurs earlier in the project lifecycle, security departments typically find that the release of budgetary funds is easier, and more commonly come from the project sponsors pot instead of theirs.