The basic premise behind security is protection against targeted or accidental malice. The principle applies to the software industry just as readily as it does to any other. Just like in the real world security in the software world revolves around various authorization models implemented in tiers and degrees of granularity. At the bottom of the chain there’s data encapsulated by information which in turn is encapsulated by resources, all up for CRUD operations leading to effect in the non-virtual world.
Currently the primary motivation for cyber attacks appear to be to steal information for financial gain and some common means to achieve that end are:
- Phishing
- Hacking
- Malware – spyware, bots, etc.
- Password Cracking
- Social Engineering
- Computer Viruses / Worms / Trojans
All of these threat templates have a life cycle that begin with malicious intent and end with some gain relevant to the perpetrator and loss to the victim. Authorization abuse is heavily involved at almost all cyber threat life cycle, so, from a software development perspective, we need to design our software based on authorization models. Unfortunately, that’s not enough, simply because authorizations may be hijacked, unless the model is perfect! Although this is only a very small play in a very large battlefield, it’s a fundamental one and plays an ever increasingly central role to threat neutralization. We should be mindful of some of the following precautionary measures in our development environments:
- Secure development environment
- Run with minimal privileges
- Secure local IIS
- Secure local database engine
- Secure production environment
- Avoid inserting test data in production database
- Avoid creating backdoors to production environment
- Code to protect
- Don’t trust user input – can lead to buffer overruns, cross-site scripting attacks, SQL injection attacks, etc.
- Protect against buffer overruns – generally c/c++ problem
- Prevent cross-site scripting – secure query string parameters
- Don’t require sa permissions – prevent sql injection
- Don’t write your own encryption algorithm
- Reduce attack profile – don’t install features you don’t use
- Employ the principle of least privilege – separate and run code requiring additional privileges in a different process
- Pay attention to failure modes – have exception handling framework and fall back to most secure mode
- Impersonation is fragile, avoid heavy reliance on it
- Write apps for non-admins
- Centralize authorization models in design and at every level, e.g., class level, library level, application level, communication level, platform level, department level, and corporate level