The good news is that over the past several years, security analysis has become a widely accepted and integral part of development and deployment processes.
The bad news is that all too often, either the wrong type of analysis or only one type of analysis is performed. Many organizations are caught in a time warp; they haven't moved beyond either standard policy and procedure audits or perimeter penetration testing, while many exploits now focus on web and application vulnerabilities. In this short article, we address additional types of testing that should be part of every application rollout.
In trying to understand the risks to your networked resources, you need to view the problem from a number of different perspectives. Each perspective reveals its own set of relevant security concerns and each relies on a particular type of analysis or test. A combination of tests is needed to gain an overall understanding of the risks in a business application environment. These additional assessments might include:
- Design review. Are the security policies, practices and procedures consistent with the business requirements? Is the security architecture consistent with best practices? Has the environment been implemented as designed? Is the operation of the environment consistent with policy?
- Web application and content review. What vulnerabilities are available solely through the web components and can web application users masquerade as others or escalate their privileges?
- Source code review. Are there security vulnerabilities inherent in the way the application was written? Is the application making assumptions about other resources or the environment that might be used to undermine its security?
- War dialing. What resources are reachable through the common phone network?
These projects provide insight into a distinct part of your computing infrastructure. Let's look briefly at how each one fills in a crucial piece of your overall information security puzzle.
Interactive Design Review
The earlier issues and problems are detected, especially design problems, the easier it is to resolve them and the more choices you are likely to have to remedy them. Making changes on paper is exponentially easier than trying to fix an application after it has already been implemented and deployed. As soon as a new design for an application or for a hosting environment is starting to take shape, it needs to be evaluated from a security perspective. One way to achieve that is to have seasoned security professionals provide an independent review of your design to validate if the models you have chosen and the tradeoffs you have made make sense in the full context of your security requirements, constraints, dependencies and priorities.
Such a review should consider a number of overarching issues such as:
- overall system and network architecture;
- network and host environment;
- critical applications and user interaction with them;
- topology/structure of gateways and firewalls, including firewall configurations and system software;
- security structure of the environment, system administration practices, policies and links to the rest of the enterprise;
- connections to ASPs and business partners;
- remote access and authentication practices and mechanisms;
intrusion detection and incident response.
This list covers a lot of ground. You might be thinking that a review of this scope would take weeks to complete. Fortunately, it doesn't have to. With the right people participating (lead technical and business people from your organization), a good review can usually be accomplished in several days of highly interactive discussion. The goal of such an exercise is to quickly get the business and security requirements, the security issues, and potential solutions on the table. With this information, you can consider the security related design alternatives in the full business context.
Source Code Review
Since most application developers focus on features and time to market and not security, it is a good idea to review the source code of important applications for good programming and security practices. The fact is, unless the application is incredibly small you are likely to have a number of teams involved in developing the code base. You may use outside programmers, have several different organizations involved in the effort, or the code may be a collection of modules developed by different companies. In any event, it is likely that the coding practices and expertise of the various groups will be dissimilar. All of these point to opportunities for error, invalid assumptions or incorrect expectations of the working environment that could lead to disastrous security holes.
In most cases, it is not necessary to review every single line of code. Intelligently selecting key modules and using a representative sampling approach is usually sufficient. Clearly, you would like to focus on modules that handle external input, modules that make calls to important database services, and modules that can be configured to have the application run in different ways. In cases where you find consistently poor coding practices in the selected modules, you'll likely find those same problems in the rest of the code base.
Web Application and Content Review
All of these types of exploits boil down to the same thing - trying to get the programs that the client talks to on your server-side to behave in unintended ways. There are many different means to accomplish this.
- Using special characters in input fields that potentially cause multiple invocation lines.
- Modifying URLs to attempt to get into unprotected spaces in the server file system.
- Modifying text in the downloaded client page to circumvent expected facilities at the server.
- Examining or modifying cookie contents to subvert server, user, or protection mechanisms.
- Analyzing data embedded in the client page (inserted by the server applications) to detect exploitable naming or invocation mechanisms, unencrypted ID information, or poor programming practices.
Assessing and fixing the vulnerabilities in your web services and applications should be a prerequisite for deployment.
One of the most often overlooked security areas is that of dial accessible services. Testing such services is usually called 'war dialing.' Exploiting phone-based services is the very root of where hacking activities started over two decades ago - hackers searching for resources that they use for free. The variety of phone-based services has increased enormously over this time. Unfortunately, with the emergence of the Internet and concerns for Internet security, there has been a corresponding decrease in the attention being paid to telephone exploitable vulnerabilities, despite the increasing number of telephone accessible resources. The types of services that tend to have dial-up facilities associated with them include the following:
- ISDN systems
- LAN management services
- PBX systems
- power monitoring systems
- printer services
- remote management applications
- routers and firewalls that have dial-up management interfaces
- terminal servers
- UPS systems.
One can see that many important facilities are reachable via dial-up connections. These connections often completely bypass all other security procedures and mechanisms. Exacerbating the problem is that dial-up services are almost never instrumented with existing intrusion detection or event management systems. Performing a dial assessment can be one of the most cost-efficient and direct ways to assess and improve the security of an important (and often forgotten) part of your IT infrastructure.
While perimeter penetration testing and policy reviews are becoming routinely accepted, other important assessments are routinely ignored. Think outside the box and choose the right assessment at the right time.
Brad Johnson is vice president and Jonathan Gossels, president, of SystemExperts Corporation (www.systemexperts.com), a provider of network security consulting services.