Think you follow safe computing practices. See how you stack up against the top 10 most dangerous things users do online.
http://www.darkreading.com/security/perimeter/showArticle.jhtml?articleID=208808175
Monday, June 29, 2009
Tuesday, June 16, 2009
Lessons from Las Vegas
A recent visitor to the SANS Penetration Testing and Web Application Security Summit in Las Vegas brought home some useful advice.
On Penetration Testing...
Many companies don’t want to know their real risk, just where the vulnerabilities are. Closing the vulnerability gap doesn’t address the root cause. In today’s regulatory environment plausible deniability is no longer a defense for poor risk management practices.
Penetration Testing is often thought of as a QA function instead of an audit and oversight function. This perception often leads to penetration tests that are, in essence, vulnerability assessments with no real measurement of risk.
Automation of pen testing is becoming more prevalent. But it still cannot take the place of live-person testing.
Vulnerability testing has a greater potential of accidentally bringing down a target server than penetration testing.
The bad guys are not necessarily going after the crown jewels directly. If they can gain a toehold somewhere in the network (desktop, network printer, mobile device) they can use that as a jumping off point and pivot to other exploits.
Patches can be bypassed using fragmentation and other evasion techniques.
Telephone connections (Modem, FAX, PBX, IVR) are still valid targets. When’s the last time you inventoried and tested your telex systems?
On Web Application Security...
Web 2.0 presents an extreme challenge to web security as we know it. Moving the execution of content to the desktop and allowing anyone to create and post content to the website will force a change in the way web security is currently handled.
If you want your developers to really understand the insecurity of web application development send them to hacker conference (Defcon, Shmoocon, Toorcon). Nothing will open up their eyes more then to listen to a presentation given by a twenty-something, dressed in black with spiked hair as he describes how he easily bypassed security and compromised the webserver/database/ network through a supposedly secure web application.
If you are not testing your entire web infrastructure you are not getting a complete picture. Using the web application to compromise the server and the server configuration to compromise the web application are both ways to get to the crown jewels.
Security testing of a web environment should occur at all access levels. By testing as a user, a web administrator and a server/systems administrator you can get a better idea of your level of risk truly is.
If you want to test the security of production elements, create a virtual image and test it offline. The virtual image will allow you to test security without affecting systems in production (though it might miss the security of other interrelated infrastructure components). Built-in virtualization and tools like VMware and Virtual PC are the best ways to implement virtualization.
Standard network security components provide very little security for web applications. The notion that one is protected from web attacks by a network firewall and IDS is false. There is very little that they can detect/block/log in web traffic. Web application firewalls, web IDS, file integrity monitoring, and web log monitoring operate mainly at the application layer and therefore will provide the greatest benefit.
On Application Code Security...
Secure code review is a valuable tool but, can be time consuming.
A secure code reviewer should be a developer rather than a security person. It’s easier for a developer to learn security than it is for a security person to learn programming.
A secure code reviewer should be in a group other than the development group. Separation of duties is important to insure accurate, uninfluenced results. It also provides validity to the results should an audit or incident investigation occur.
Pay attention to systems as a whole and not just the applications.
On Penetration Testing...
Many companies don’t want to know their real risk, just where the vulnerabilities are. Closing the vulnerability gap doesn’t address the root cause. In today’s regulatory environment plausible deniability is no longer a defense for poor risk management practices.
Penetration Testing is often thought of as a QA function instead of an audit and oversight function. This perception often leads to penetration tests that are, in essence, vulnerability assessments with no real measurement of risk.
Automation of pen testing is becoming more prevalent. But it still cannot take the place of live-person testing.
Vulnerability testing has a greater potential of accidentally bringing down a target server than penetration testing.
The bad guys are not necessarily going after the crown jewels directly. If they can gain a toehold somewhere in the network (desktop, network printer, mobile device) they can use that as a jumping off point and pivot to other exploits.
Patches can be bypassed using fragmentation and other evasion techniques.
Telephone connections (Modem, FAX, PBX, IVR) are still valid targets. When’s the last time you inventoried and tested your telex systems?
On Web Application Security...
Web 2.0 presents an extreme challenge to web security as we know it. Moving the execution of content to the desktop and allowing anyone to create and post content to the website will force a change in the way web security is currently handled.
If you want your developers to really understand the insecurity of web application development send them to hacker conference (Defcon, Shmoocon, Toorcon). Nothing will open up their eyes more then to listen to a presentation given by a twenty-something, dressed in black with spiked hair as he describes how he easily bypassed security and compromised the webserver/database/ network through a supposedly secure web application.
If you are not testing your entire web infrastructure you are not getting a complete picture. Using the web application to compromise the server and the server configuration to compromise the web application are both ways to get to the crown jewels.
Security testing of a web environment should occur at all access levels. By testing as a user, a web administrator and a server/systems administrator you can get a better idea of your level of risk truly is.
If you want to test the security of production elements, create a virtual image and test it offline. The virtual image will allow you to test security without affecting systems in production (though it might miss the security of other interrelated infrastructure components). Built-in virtualization and tools like VMware and Virtual PC are the best ways to implement virtualization.
Standard network security components provide very little security for web applications. The notion that one is protected from web attacks by a network firewall and IDS is false. There is very little that they can detect/block/log in web traffic. Web application firewalls, web IDS, file integrity monitoring, and web log monitoring operate mainly at the application layer and therefore will provide the greatest benefit.
On Application Code Security...
Secure code review is a valuable tool but, can be time consuming.
A secure code reviewer should be a developer rather than a security person. It’s easier for a developer to learn security than it is for a security person to learn programming.
A secure code reviewer should be in a group other than the development group. Separation of duties is important to insure accurate, uninfluenced results. It also provides validity to the results should an audit or incident investigation occur.
Pay attention to systems as a whole and not just the applications.
Tuesday, June 2, 2009
Follow OCIO on Facebook, YouTube, Twitter
You can now to follow the Office of the Chief Information Officer (OCIO) on Facebook, YouTube and Twitter. Maintaining our commitment to keep the public and information technology community updated on the latest news and information, the OCIO has established accounts on these popular social networking sites. Please sign up, log in and follow along!
Twitter: www.twitter.com/CaliforniaCIO
Facebook: http://www.facebook.com/pages/Sacramento-CA/Office-of-the-Chief-Information-Officer-State-of-California/84270800986?v=wall&viewas=1651807453
YouTube: www.youtube.com/CaliforniaCIO
Twitter: www.twitter.com/CaliforniaCIO
Facebook: http://www.facebook.com/pages/Sacramento-CA/Office-of-the-Chief-Information-Officer-State-of-California/84270800986?v=wall&viewas=1651807453
YouTube: www.youtube.com/CaliforniaCIO
Subscribe to:
Posts (Atom)
Posts
