Beyond Penetration Testing
- Details
- Category: Application Security
Good article on the fact that many organizations rely too heavily on Penetration Testing (AppScan, Web Inspect, Etc) and not enough on other technologies.
A good approach towards Application security is multi-faceted. Whitebox, blackbox, and various other techniques INCLUDING training your developers!
read more on this article by clicking here
New MySQL Vulnerability
- Details
- Category: Application Security
Sorry for the delay.
On March 28, 2011, it was announced that there was a breach of MySQL via an SQL Injection.
When will people finally get it that these vulnerabilities are common and need to be taken care of?
The seriousness of these types of issues have been around for a long time. We can close certain loop-holes, but the attackers are getting more and more ingenious in the way they attack. Sometimes even the more simple things are overlooked.
This is the link below for further information:
Wordpress Incident
- Details
- Category: Application Security
Wordpress announces that there was a "Security Incidence" with their software.
The "Incidence" described is a low-level issue where the servers were compromised. Not a great way to start the day.
Please take the time to follow any and all suggestions if you or someone you knows runs this software.
This is the link:
http://en.blog.wordpress.com/2011/04/13/security/?utm_source=twitterfeed&utm_medium=twitter
Simplistic approach to Application Security
- Details
- Category: Application Security
There are a ton of different ideas and theories out there concerning Application Security.
Please remember that many of these directions and ideas are driving by business needs and dogma. I know this is going to anger a few people and for that I am sorry. But the realism is that sometimes the information you receive is based upon a companies need to control you the user. So their ideas may NOT be 100% correct.
A straight-forward, simplistic approach to Application Security is a combination of all of the following:
1) Take Security OUT of the initial Risk Management assessment for all projects. Security must be present throughout your SDLC. You don;t build a network and incorporate Security measures only to stop there do you? How can you write an application and not place it into a continuous testing loop as well ? New vulnerabilities and techniques to find them are being discovered every day. So keep on top of it. Continue to test the application through black box or Penetration testing even after the application is in production. In my opinion, Project Management Principles MUST be updated. They are out dated and need to be changed periodically to include new directions.
2) Training. Get your developers the training they need to stop writing code that may contain insecure coding methods. Trust the developer to learn at their own speeds. CBT training is one of the best, but follow up with group discussions and periodic meetings. Sort of like your own internal Developer User Group. I've been deeply involved in my career with quite a few of these groups. There is power in sharing ideas and utilizing the knowledge of others to help a developer.
3) Oversee. Trust your developers through code review by independent developers or developers in other areas. Do not trust that the person sitting next to a developer to review the work. Group reviews, group discussions and group assessments are the best way to go.
4) Testing. All testing should be handled within your Security Department. This might mean external consultants, companies or individuals who are adept at Application Security testing. If you do have someone on site and in your Security Department that can handle the testing, keep them up to date. A person that only spends a few hours a month testing will inevitably miss more vulnerabilities. A dedicated person is great but a person that can be utilized 50% or greater is better than 5% or none at all.
Testing should be done with various tools. No one tool is perfect and should be trusted. Automatic and manual testing techniques are probably the best way to go.
Give the person the time to test an application. If you only schedule a day for Application Security Testing on an application that contains 10 or more data entry pages, don;t expect this to get done over night. Low hanging fruit (easily found vulnerabilities) may only indicate a larger problem. No Vulnerabilities found
5) Maintenance. Maintain log reviews, periodic application testing should be a normal event added to your Network Intrusion, Network testing cylces. Hackers continue to find new ways into applications. They new ways are discovered and incorporated into automatic or manual testing procedures. Thus, this is a never ending cycle here until the application is retired. A legacy application may be forgotten and found to be vulnerable. If we forget about an application due to its long term usage or "its always been there" mentality, a hacker will find it and exploit it.
I will try to break down each section more throughout this section, in time.
Application Security, general statement
- Details
- Category: Application Security
Over the next few weeks, I will be updating a great deal of information here concerning Application Security. Its one of my talents, to be able to pen test applications, audit and suggest things. I still find it amazing that AppSec is still frowned upon in many ways. We can prove that problems exist, we can show them how we pulled back information through a web application, we can show them and teach them.... but the lights are still not on.
In some ways they are slowly starting to turn on. Which is a good thing. But we need more awareness of the problem to be able to fix a lot of the problems that are out there.
Check back for more things in the near future!
Thanks
