I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 5 of 5 so please be sure to read parts 1, 2, 3, and 4.
Training, outreach, and networking
We decided to leverage existing communications avenues (mailing lists, newsletters, status reports, etc) as well as setup a Wordpress blog. We used these tools to publish information about security news, link to 3rd party security documentation, security guidance, solicit feedback and most importantly, identify individuals throughout the organization that had interest or skills in secure software development. Our goal with the outreach program was not only to make information resources available, but also to ensure that our services were transparent and accessible. Like us, most security groups have to overcome the stigma of being a crazy bunch of paranoid hackers who cost the company money and cause deadlines to slip. As such, the outreach program coupled with our threat modeling and security consulting services were delivered with clarity, transparency, and comprehensiveness.
We also delivered numerous training courses aimed at educating developers and architects in defensive programming, software vulnerabilities, and threat modeling. These courses were typically delivered to smaller audiences and accompanied with hands on activities. We found that these courses were not only being well received, but also that attendees would contact us to request additional training tailored to a specific topic that would be relevant to their products. I feel that we had the distinct benefit of having team members who were very adept at delivering training and realize that not all organizations have this sort of resources. Given a high enough priority in company goals, training can easily be purchased, and employees who are members of professional groups can leverage relationships with professionals outside the organization who would be willing to deliver the training.
For more information on homegrown security teams, checkout my post.
In this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. Jeremiah Grossman (WhiteHat Security / OWASP) and Jeff Williams (Aspect Security / OWASP) have collaborated on a fantastic article that is sure to get security engineers, developers, and managers alike lining up at their executives’ door armed with some great arguments in support of creating or expanding their application security programs.
While I fully support and endorse the content of the article, I can already see the responses from some executives:
“Wow, this is really great, and I fully buy into it, but as it stands, there is REALLY no money extra money in the budget.”
What now? Hopefully, there are employees in your company who are responsible for managing servers, the domain, the networks/firewalls/IDS/IPS, and development efforts; but most importantly, you, who is concerned about the state of application security. Why not use some of the best resources from those groups to form an application security working group? I’ve found that no matter what the company, there are ALWAYS people that are interested in being able to devote some time to learning about how those sneaky hackers are able to break into so many systems. Furthermore, what (good) technologist wouldn’t be interested in expanding their skills?
I’m sure that you’ll encounter some resistance from employees and management alike, after all, time is valuable, but remember, Jeremiah and Jeff have already given you all the ammo you need; use it wisely.
Now that you’ve identified folks who are willing to donate some of their valuable time to this effort, your first step will be educating them about the various activities and processes involved with a complete application security program. Here’s a quick reminder:
Design and architecture reviews and threat models where you work to identify flaws in the application design and architecture as well as imposing security requirements.
Secure coding standards where you work to ensure that developers implement features such as input validation, authentication, authorization, and avoid creating flaws in the business logic as they move through implementation.
Code reviews where through either automated or manual means, developers review their code with a focus on identifying any security issues.
Testing and validation where you ensure that all requirements have been implemented according to design specs.
Deployment and maintenance where you ensure that logs are being monitored, system patches are being kept up to date, and 3rd party libraries used in the application are kept up to date.
The chances are good that some of the folks that have chosen to join the security working group already have some valuable input to provide. For example, the sysadmins might have expertise in Apache, host configuration management, or IPTables. The network folks might have been exposed to web application firewall technology. The developers might have some great security specific libraries that they’ve used on past projects. All of this knowledge is valuable and already at your finger tips. For other topics, search around your social network, if you’re on Twitter, checkout @securitytwits, if you’re a member of OWASP, attend the meetings, talk to folks, try to get an idea of their expertise. Many of the seasoned security professionals who attend these meeting would be happy to come in and present at one of your groups meeting.
So, get out there, talk to people both within and outside of your company, not only will you expand your social network and improve your companies application security program, but you’ll also be giving new opportunities to those who join the security working group.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 5 of 5 so please be sure to read parts 1, 2, 3, and 4.
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin