Consider these security issues when building an application
We have been building applications for many years, but we are finding that our security is getting much more scrutiny than it did in the past. This is understandable given the well-publicized hacking and virus proliferation over the past few years, and it has been heightened by the September 11 attacks. We think our applications are secure, but what are the major aspects of security we should be aware of?
—Tim M.
Answer:
Tim,
It seems not a day goes by
when we don’t hear or read something about security or the lack of it. The
government initiative about homeland security keeps us at a heightened level of
sensitivity. So it’s no wonder our managers and business users want to be more
comfortable with the level of security we’re building into our applications. In
the old mainframe days (I know, here he goes again), this was less of a concern
because the monolithic software was very stable and secure. There were also many
fewer points of entry into the computer network. Today, the approach to security
needs to be multi-faceted, since there are many potential points of
vulnerability.
The broad topic of security is too large to cover in one
column, but I can share some of the general issues you should consider. Some of
these are within the control of the developer, while others need to be
implemented within the infrastructure. Note that not all applications need to be
highly secure. Your company intranet, for instance, should be accessible to
anyone behind your firewall. However, you should consider the following points
for each application.
- Online access. Only authorized users should be able to access online applications, usually through a secure user ID and password. Depending on how secure you need the application to be, you can set the passwords to expire, require them to have a mix of characters and numbers, and revoke a user ID if you detect a number of invalid passwords entered. You can also employ the user ID as a way to limit access to certain features and functions of the application once the user gets in.
- Network infrastructure. Your company should keep its internal applications behind a secure firewall. Some firewall configurations are more secure than others; the one your company chooses will depend on the enterprise’s level of security and control needs. You must strictly control and monitor access from outside the firewall into your network, whether via dial-up, VPN, or other method. If you allow third-party access, you must control and monitor it in the same way.
- Production data. You should secure your data from unauthorized updates. We all know how convenient it is to be able to “fat-finger” production data when there’s a problem, but this is not a secure practice. Every table or file update should be secure, restricted to production processes, and logged. Database and system administrator access should likewise be controlled and logged.
- Reports. You may need to make sure that confidential reports are printed in a controlled environment, or that the printing and delivery processes are subject to monitoring and audit.
- Separation of duties. This is business-level security used to ensure that one person does not control multiple parts of a process that they could manipulate intentionally or unintentionally for their own gain.
- Internal development. You should have good software change management policies and tools to ensure that only authorized and detectable changes are made to the software programs.
- Physical security. You may need to ensure that physical aspects of an application are secure. For instance, if you have a client-server application, you may need to ensure that the client machines (laptops, for example) do not contain any sensitive information that could be compromised if they were lost or stolen.
This list provides some background on the areas you may need to consider when building an application. If the application you’re building needs to be very secure, you might consider bringing in a security expert for consultation.
You can also bring in internal or external auditors to go over your application, business, and infrastructure controls to make sure you’re maintaining vigilance and not developing security gaps. In many cases, security gaps are not technical problems, but the breakdown of manual processes. For instance, you may be logging all attempts for unauthorized access, but is someone monitoring and analyzing the information to detect the abuses?
Conclusion
An application isn’t adequately protected unless security is part of the business requirements designed into the application, subsequently built, and rigorously tested. However, that’s not the whole story. Application security also relies on secure company infrastructure and sound business processes.