With your team gathered and your new SOA developed, now is the time to test its security. Testing allows you to see whether the vision matches the promise of success.
Testing should occur in two phases: preproduction and production. Preproduction testing is the final step before any new application or hardware solution is allowed any outside access. This testing, designed to mimic the production environment, should push not just security but also load, process, and function.
There are often subtle differences between preproduction and production environments—for example, hardware, operating system configuration, and firewall settings. Therefore, during production testing, you recheck the improvements to security that were made in preproduction.
Start your testing by establishing which components you must test and how best to test them. Can non-administrative users gain administrative privileges? Is private data hidden from users without permissions? Can common hacking scripts find holes that have been overlooked? Does Structured Query Language (SQL) injection fail? Be sure to think outside the box and consider any tools that malicious users may employ to penetrate your security. By considering the security of internal and external items, you cover the greatest amount ground in both phases of testing.
Document which test to conduct and when. Scheduling testing is important for keeping testers and developers from tripping over each other. Tests break applications, so it's important to know which test caused the damage. Also, you may need to run some tests after hours, so finding the right people is significant.
You formed your team back in step 1 of Part 1 of this series. Select members from that team best suited to assist with security testing. Testing teams often take shape during the building stages as people naturally collaborate on functionality, support, and usage of the new SOA. Make sure that as these teams form, security experts are incorporated into the groups.
Also consider bringing in neutral parties to help during testing. These testers can be select users or developers who are not part of the final SOA design. Such testers can offer an impartial opinion of how well features work and whether security is working properly. Seeking advice from outside security professionals in the early stages can also bring in a wealth of information. Dedicated to security matters, these professionals can offer unconventional advice for securing data from unauthorized access. Professional security firms typically offer different specialties, as well, such as networking, applications, and hardware, that can augment the knowledge of your current staff. These groups usually have direct vendor support and thus can often provide high-level information not easily found elsewhere.
After building a testing team, assign tests. Communicate to team members how they should conduct the tests and the results they should expect. Record questions with known answers in written checklists that show the "before and after" results. Not only will testers perform tasks in the correct order, but they will also see whether the results are what the developers were expecting. Just because an application offers a result doesn't mean it's the correct result. For example, if the new SOA is part of a customer order system, check the math. Are shipping fees and taxes being calculated correctly?
Security testing should follow both programming and industry standards. Industry compliance standards, such as the Payment Card Industry (PCI) and the Health Insurance Portability and Accountability Act (HIPAA), have specific rules concerning how data is handled.
Set up the preproduction environment
Always consider using a dedicated preproduction environment to test changes before going live with them. The preproduction environment should match the production systems as closely as possible. This becomes critical when you're testing load and security. Sometimes, the small differences are key, such as using the same flavor of Linux® in both environments.
Say, for example, that your new SOA application is built to use IBM® WebSphere®. Both the testing and the production systems have the current version of WebSphere installed and updated. However, the production environment uses SUSE Linux, while the testing environment is loaded with Red Hat Linux. While the differences between the two Linux flavors are small, the patching of components can be the difference between the new application failing and functioning properly when put into production.
It is not uncommon for businesses to use older servers for preproduction, employing the better, faster hardware in the production environment. This decision makes sense for economic purposes but can cause problems when testing how security holds up with load and speed variables.
The problem can be exaggerated when the production environment uses multiprocessor hardware with lots of memory while the test environment hardware uses a single processor with barely 1 GB of RAM. Simplify the problem by keeping within the same generation of processor and the same amount of RAM as well as standardizing your hardware vendor. Standardizing hardware offers the benefits of similar drivers and components in both environments.
Consider using virtual servers loaded with a backup of your production servers to create your preproduction environment. Having an exact copy of the production environment within a virtualization product, such as VMware, simplifies server setup. If a particular test breaks the server, testers can reestablish the server by loading a cloned copy of it.
Before implementing your SOA to the outside world, decide how you will handle a security breech. Say you come in one day and see a cursor moving independently or find packaged files of user data moved to the FTP server. Do you immediately pull the plug? Call the police? Hop the first plane to Bermuda?
Having an established and well-informed plan will curtail some of the panic that comes with security intrusions. At a minimum, security breech response plans should include a list of contacts, an initial response team, and basic instructions. Your list of contacts should include technical expertise as well as important stakeholders, such as the company president.
Basic instructions tell staff what to do first and identify the best method for preserving evidence. These instructions should also include the correct order in which to perform tasks—for example, should they should pull the plug or call the Chief Information Officer (CIO) first?
The response team should include information technology (IT) experts and essential managers. Managers can be the point of contact to other departments to explain why a system is down. They can also keep the situation calm, as word of the breech may cause panic. For example, a manager can warn Customer Service that the Web site is down so that they know to expect a higher call volume. Managers can also construct how customer service agents address customers so as not to alarm them.
Also, consider having an outside forensics team as part of the response team to help assess damage. Outside vendors will have "cooler heads" than invested employees and can also bring in law enforcement-grade forensic tools.
Completing preproduction testing and moving the application to the production servers doesn't signal an end to testing. Production testing is the final exam of your SOA. Remember that the environment in which you test will inevitably have slight differences from the production environment: While you're building your SOA, your current environment is a living organism. Minor changes such as firewall configuration, server patches, and anti-virus updates can play a factor in security from preproduction.
One of the best security tests to perform before an SOA is moved to production is a penetration test. Penetration tests hammer the SOA application from the outside to try to crack security. These tests are best left to a Certified Ethical Hacker (CEH): They have the tools and the knowledge to try the best tricks for sneaking inside your organization. CEHs use multiple methods of attack to exploit poor operating system patch installations or bad application code.
Penetration testing is typically performed at least twice. The first pass looks for errors in security, which are reported to the SOA team. The second and subsequent tests are done after flaws found in the first test have been corrected. Having a CEH perform a "blind" penetration test can reveal a lot about your SOA. During such a test, the CEH is given minimal information about the infrastructure before he or she attempts to hack the system. In this way, the CEH gets a real-world scenario of what an outside hacker would need to discover before attempting to infiltrate the environment. These tests can bring up some surprises that insiders thought were well hidden.
While you may want to rush implementation of your new SOA, don't take shortcuts to security. By building upon the fundamentals of SOA, you keep your data in the right hands. Even after your new SOA is put into service, continue to use the following security measures:
- Build security teams out of your SOA development group.
- Develop tests and offer expected results.
- Test improvements in environments separate from production.
- Establish and maintain security standards.
- Use penetration tests before rolling out the SOA and on a regular basis afterwards.
- Participate in the discussion forum.
- Read the entire three-part series.
-
Check out developerWorks blogs
and get involved in the developerWorks
community.
-
Download IBM
product evaluation versions and get your hands on application development tools
and middleware products from DB2®, Lotus®, Rational®, Tivoli®,
and WebSphere.
Michael Welsh is a 15-year IT professional specializing in IT security, disaster recovery, and networks. He is also knowledgeable in operating systems, hardware, and many server-side applications such as Microsoft Exchange Server. Michael writes technical articles and documentation for Web sites and businesses.
