There hasn't been quite enough information provided to help guide you down to specifics, but let's take a shot.
It sounds like you're still discussing thin-client web-based applications and hardening your intranet environment. One of the questions to ask is if you're a "buy vs build" company - meaning, do you buy an application to fill a business need, or do you develop an application to fill a business need?
Penetration testers can check the applications for classic vulnerabilities - buffer overflows, cross-side scripting, sql injection, etc, but may not catch everything. Your best bet is, rather than relying on pen testing existing applications (or perhaps in addition to), to bake secure development habits into your software development lifecycle. This only works if your organization is developing these applications in-house.
Any isolated environment will permit pen testers to cleanly focus on this application, but they can also test in your production environment.
The other thing you may want to consider (regardless of the buy vs build argument) is having a standardized architecture in which to implement software on. The term 'Standard' isn't meant to imply 'homogenous' -- you can have a standard architecture for.net applications and a standard architecture for Java-based apps. Have standard server builds that are hardened for app serving. Part of deploying and maintaining a secure application is deploying correctly; changing default passwords, encrypting credentials when database calls are made, etc.
To further the 'standard architecture' discussion, you could even focus on the B2X approach; have a relatively isolated environment for your internally-facing applications (Business-to-Employee or B2E), and have another, perhaps more-hardened environment for your business customers (the business-to-customer or B2C environment), and finally, business-to-business connections (B2B) can use yet another environment. Strong policies and adherence to these policies around secure restrictions to develop and deploy in these environments will be very helpful. Standard architectures also permits you to layer your security; don't just look at the app; look at the database calls, the server configuration, services that are running, patches that have been applied, firewall configurations, etc. Harden the environment, not just the app. I'm more a believer in the standard architecture, rather than the penetration tester, myself. Best of luck.:)
Haha sorry, I swear when I typed that up, it had paragraphs, page breaks, sunsets and unicorns, the whole deal. It was my first/. post; is there something special you need to check to force line breaks?
There hasn't been quite enough information provided to help guide you down to specifics, but let's take a shot.
It sounds like you're still discussing thin-client web-based applications and hardening your intranet environment. One of the questions to ask is if you're a "buy vs build" company - meaning, do you buy an application to fill a business need, or do you develop an application to fill a business need?
Penetration testers can check the applications for classic vulnerabilities - buffer overflows, cross-side scripting, sql injection, etc, but may not catch everything. Your best bet is, rather than relying on pen testing existing applications (or perhaps in addition to), to bake secure development habits into your software development lifecycle. This only works if your organization is developing these applications in-house. If you are more Applications will have vulnerabilities that will need to be identified and fixed; well-trained penetration testers can assist with this.
An isolated environment will permit pen testers to cleanly focus on this application, but they can also test in your production environment.
The other thing you may want to consider (regardless of the buy vs build argument) is having a standardized architecture in which to implement software on. The term 'Standard' isn't meant to imply 'homogenous' -- you can have a standard architecture for.net applications and a standard architecture for Java-based apps. Have standard server builds that are hardened for app serving. Part of deploying and maintaining a secure application is deploying correctly; changing default passwords, encrypting credentials when database calls are made, etc.
To further the 'standard architecture' discussion, you could even focus on the B2X approach; have a relatively isolated environment for your internally-facing applications (Business-to-Employee or B2E), and have another, perhaps more-hardened environment for your business customers (the business-to-customer or B2C environment), and finally, business-to-business connections (B2B) can use yet another environment. Strong policies and adherence to these policies around secure restrictions to develop and deploy in these environments will be very helpful.
Standard architectures also permits you to layer your security; don't just look at the app; look at the database calls, the server configuration, services that are running, patches that have been applied, firewall configurations, etc. Harden the environment, not just the app.
I'm more a believer in the standard architecture, rather than the penetration tester, myself.
Best of luck.:)
Slashdot Mirror
fixed :p
There hasn't been quite enough information provided to help guide you down to specifics, but let's take a shot.
It sounds like you're still discussing thin-client web-based applications and hardening your intranet environment. One of the questions to ask is if you're a "buy vs build" company - meaning, do you buy an application to fill a business need, or do you develop an application to fill a business need?
Penetration testers can check the applications for classic vulnerabilities - buffer overflows, cross-side scripting, sql injection, etc, but may not catch everything. Your best bet is, rather than relying on pen testing existing applications (or perhaps in addition to), to bake secure development habits into your software development lifecycle. This only works if your organization is developing these applications in-house.
Any isolated environment will permit pen testers to cleanly focus on this application, but they can also test in your production environment.
The other thing you may want to consider (regardless of the buy vs build argument) is having a standardized architecture in which to implement software on. The term 'Standard' isn't meant to imply 'homogenous' -- you can have a standard architecture for .net applications and a standard architecture for Java-based apps. Have standard server builds that are hardened for app serving. Part of deploying and maintaining a secure application is deploying correctly; changing default passwords, encrypting credentials when database calls are made, etc.
To further the 'standard architecture' discussion, you could even focus on the B2X approach; have a relatively isolated environment for your internally-facing applications (Business-to-Employee or B2E), and have another, perhaps more-hardened environment for your business customers (the business-to-customer or B2C environment), and finally, business-to-business connections (B2B) can use yet another environment. Strong policies and adherence to these policies around secure restrictions to develop and deploy in these environments will be very helpful. Standard architectures also permits you to layer your security; don't just look at the app; look at the database calls, the server configuration, services that are running, patches that have been applied, firewall configurations, etc. Harden the environment, not just the app. I'm more a believer in the standard architecture, rather than the penetration tester, myself. Best of luck. :)
Haha sorry, I swear when I typed that up, it had paragraphs, page breaks, sunsets and unicorns, the whole deal. It was my first /. post; is there something special you need to check to force line breaks?
There hasn't been quite enough information provided to help guide you down to specifics, but let's take a shot. It sounds like you're still discussing thin-client web-based applications and hardening your intranet environment. One of the questions to ask is if you're a "buy vs build" company - meaning, do you buy an application to fill a business need, or do you develop an application to fill a business need? Penetration testers can check the applications for classic vulnerabilities - buffer overflows, cross-side scripting, sql injection, etc, but may not catch everything. Your best bet is, rather than relying on pen testing existing applications (or perhaps in addition to), to bake secure development habits into your software development lifecycle. This only works if your organization is developing these applications in-house. If you are more Applications will have vulnerabilities that will need to be identified and fixed; well-trained penetration testers can assist with this. An isolated environment will permit pen testers to cleanly focus on this application, but they can also test in your production environment. The other thing you may want to consider (regardless of the buy vs build argument) is having a standardized architecture in which to implement software on. The term 'Standard' isn't meant to imply 'homogenous' -- you can have a standard architecture for .net applications and a standard architecture for Java-based apps. Have standard server builds that are hardened for app serving. Part of deploying and maintaining a secure application is deploying correctly; changing default passwords, encrypting credentials when database calls are made, etc.
To further the 'standard architecture' discussion, you could even focus on the B2X approach; have a relatively isolated environment for your internally-facing applications (Business-to-Employee or B2E), and have another, perhaps more-hardened environment for your business customers (the business-to-customer or B2C environment), and finally, business-to-business connections (B2B) can use yet another environment. Strong policies and adherence to these policies around secure restrictions to develop and deploy in these environments will be very helpful.
Standard architectures also permits you to layer your security; don't just look at the app; look at the database calls, the server configuration, services that are running, patches that have been applied, firewall configurations, etc. Harden the environment, not just the app.
I'm more a believer in the standard architecture, rather than the penetration tester, myself.
Best of luck. :)