Dos and don'ts: Ensuring apps security from the get-go |
 |
By Jan Stafford, Editor
24 Aug 2005 | SearchOpenSource.com |
|
|
Some people accept that software will have security flaws and that IT managers' and users' bad security practices will exacerbate those flaws. Software engineer Mark Patterson, however, believes that closing the gap between users and developers will result in more secure applications and networks.
Patterson believes it is the gulf between the developers and users that has perpetuated the ongoing software security crisis. If developers and IT managers work as a team, both the flawed software- and user error-caused application security breaches are fixable, said Patterson in an interview with SearchEnterpriseLinux.com. Patterson is engineering vice president for Secure Software Inc., an application security technology and services provider in McLean, Va.
Don't choose an application whose developers fail to consider security a top priority and practice excellent security practices.
Security is and must be a core requirement for any application, so choose a vendor or open source project that practices software security best practices throughout the development lifecycle. "This includes threat modeling, specifying the intended operational environment, defining of use and misuse cases, adopting of secure coding techniques, and performing source-level security reviews including source code analysis," said Patterson. The same standards should apply to in-house developers.
Do develop a close relationship with your application's developers.
Developers and IT managers should collaborate on security requirements from very early in the application development lifecycle, said Patterson. During that collaboration, IT managers should make sure that appropriate security is built in to an application. Ask developers for help in implementing the right operational controls during deployment.
Do follow the application developer's deployment recommendations.
Yes, some folks don't follow directions. For example, Patterson has seen people deploying a Web application without following the recommendation for the correct use of SSL (Secure Sockets Layer). In this case, a breach caused by the interception of unencrypted Internet traffic would not be the fault of the application, but in how it was deployed in production.
"The IT organization must take into account all deployment recommendations, controls and limitations of the application, and enforce a policy that prohibits installing and operating the software outside these boundaries," Patterson said.
Don't focus all security efforts on the perimeter of your network.
"Most IT administrators focus on the network tier, deploying firewalls, intrusion detection, and other perimeter-defense or monitoring mechanisms," said Patterson. "In addition, applications exposed to the outside typically employ encryption methods like SSL to provide privacy of communications on the Internet and to ensure the identities of the endpoints are trusted."
These are necessary efforts to protect internal IT resources from external attackers; but they do not go far enough, in Patterson's opinion. For one thing, IT organizations must consider internal threats from employees, contractors, and software systems that are not adequately addressed using perimeter technology. Also, coding flaws make many applications inherently insecure.
Applications that are exposed on the Internet are particularly vulnerable to flaws such as buffer overflows and cross-site scripting, and those can only be addressed by employing secure coding practices," said Patterson.
|
|
|
|
