3

I work as an application architect at larger company that builds web applications using both .Net and Java technologies. These are sold to and accessed by other businesses (not consumers). We have multiple application development teams working on these, including various skill levels of employees, contractors/consultants and outsourced teams.

We have a mature Information Security group, data center operations, networking. etc. We also have mandatory application security training, scans of source code with third party software and guidance via security policies and procedures.

i’m trying to advocate for a smaller team (3-4 people) that could focus on detailed, code level implementation and remediation items from audits and scans. These individuals would understand how the OWASP Top 10 looks like in code and over the network, and not viewed as a management checklist.

Question: I’m looking for information about the right skill mix in building this team, preferring any documented case study, but opinions also hold value. I want to avoid a generic list like: Java developer, .Net developer, tester, DBA, etc.

Also, trying not to make this a subjective, open ended question - so would appreciate any recommended edits.

  • IMO, you are answering yourself. You're looking for Java and .NET developers that follow OWASP best practices. That's it. – yzT Jan 27 '14 at 6:42
  • 1
    IMO, if a person can't write exploit code they have no business being in this team. Make sure they understand post-exploitation. When we are recruiting this is an area that we focus on, and most recruits fail in understanding why vulnerabilities are valuable to a hacker. Sure they can find some vulnerabilities, but that isn't enough to keep you from getting hacked. – rook Jan 27 '14 at 16:10
  • @Kevin, Why not look for software developers that has a "security focus" (e.g. 3 yr exp with pentesting and etc)? – Pacerier Jan 28 '16 at 10:56
1

Cigital's Building Security In Maturity Model (BSIMM) is a detailed study of software security initiatives in 67 organizations. All BSIMM participants have an internal group devoted to software security called the Software Security Group (SSG). The BSIMM FAQ describes the role of characteristics of the software security group (SSG) at http://bsimm.com/facts/.

According to the BSIMM FAQ the "SSG size on average is 14.78 people (smallest 1, largest 100, median 7) with a "satellite" of others (developers, architects and people in the organization directly engaged in and promoting software security) of 29.6 people (smallest 0, largest 400, median 4). The average number of developers among our targets was 4,190 people (smallest 11, largest 30,000, median 1,600), yielding an average percentage of SSG to development of just over 1.4%."

Gary McGraw, Sammy Migues, and Jacob West discuss the rationale and benefits of the SSG, particularly in the context of an comprehensive software security program covering the software development life cycle. They found the "percentage of SSG to development of 1.4% in the sixty-seven organizations we studied. That means one SSG member for every 71 developers. The largest SSG was 27.27% and the smallest was 0.03%."

Though none of the sixty-seven SSGs we examined had exactly the same structure (suggesting that there is no one set way to structure an SSG), there are some commonalities we observed that are worth mentioning. At the highest level of organization, SSGs come in three major flavors: those organized according to technical SDLC duties, those organized by operational duties, and those organized according to internal business units. Some SSGs are highly distributed across a firm, and others are very centralized and policy-oriented. If we look across all of the SSGs in our study, there are several common "subgroups" that are often observed. They are: people dedicated to policy/strategy and metrics; internal 'services' groups that (often separately) cover tools, pen testing, and middleware development/shepherding; incidence response groups; groups responsible for training development and delivery; externally-facing marketing/communications groups; and, vendor-control groups.

For more about this issue see Gary McGraw's informIT article 'You Really Need an SSG' at http://www.informit.com/articles/article.aspx?p=1434903

0

I think you want to build up a blueteam that can do remediation after pentesting. So they should know about secure coding, code analysis, reverse engineering. They must understand deeply about how the code was processed on diffirent platforms. I can say that it's very challenge.
Since you have IS group already, you can choose some from them. It's suppose not easy to build this team from coding engineers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.