Mark O'Neill asked a tough question - "Who Manages Application Gateways?", the heart of the matter is -
So, breaking it down, there are two things going on here: (1) moving integration and security tasks onto network infrastructure, and (2) managing the Gateway as a piece of network infrastructure. It follows logically that there are two distinct roles involved here: (1) The person configuring services and policies on the Gateway, and (2) the person operationally managing the Gateway. Person (1) knows about APIs, apps, and policies. Person (2) does not need to know anything about APIs (much less know anything about REST or XML) but knows all about SNMP, Splunk, load-balancers, and NAT.
I've long described AppSec as a Texas Leaguer problem. For people who are not into baseball - a Texas leaguer is a weak fly ball that two fielders could catch but each thinks the other will get it and so neither runs to it and the catchable ball drops in for a hit. (I try to ask international audiences if there is a cricket equivalent but I have not uncovered one yet).
AppSec is the exact same problem. Developers don't know enough about security and security people don't know about software. So you have this massive gap that allows solveable problem after solveable problem to remain unsolved.
Ops adds another dimension to this problem and perhaps in looking for developers and security people to solve the problems we've been ignoring a leading candidate. The problem that Mark O'Neill describes is a classic DevOps problem and a Security DevOps role would be able to fill a number of these gaps.
The most famous Texas Leaguer happened to the 1962 New York Mets one of the worst teams of all time.
New York Mets center fielder Richie Ashburn and Venezuelan shortstop Elio Chacón found themselves colliding in the outfield. When Ashburn went for a catch, he would scream, "I got it! I got it!" only to run into Chacón, who spoke only Spanish. Ashburn learned to yell, "¡Yo la tengo! ¡Yo la tengo!" instead. In a later game, Ashburn happily saw Chacón backing off. He relaxed, positioned himself to catch the ball, and was instead run over by left fielder Frank Thomas, who understood no Spanish and had missed a team meeting that proposed using the words "¡Yo la tengo!" as a way to avoid outfield collisions. After getting up, Thomas asked Ashburn, "What the heck is a Yellow Tango?"
Security can feel like playing for the New York Mets - there's a lot of ground to cover and many domains that need to work together. AppSec has this problem in spades - deep app knowledge, operational/infrastructure management, assurance, and security protocol expertise to develop the technical policies, all must work together to avoid collisions.
This mix of software, ops, assurance testing, and security protocols is quite important in a Security role more so than almost any IT function because security is a system level property but the mechanisms only work at a functional level. So each mechanism must make sense in a wider context and a project by project incremental view won't give you the security you need. I mentioned this as a core issue in a chat with Marcus Ranum:
Marcus Ranum: Gunnar, your blog (1 Raindrop) is one of my favorite security forums, since you seem to be as comfortable with “the big picture” strategic problems as well as the practicalities, and you do it fluently and coherently -- do you realize how rare that is?
Gunnar Peterson: Thanks for the kind words on the blog. In terms of bouncing between big picture and practical issues, I think this is a must in security. We’re vulnerable to poor design and implementation. Getting the level of abstraction calibrated correctly is one of the enduring challenges in infosec. How many times have we seen a big picture policy or architecture document essentially filled with low-level configuration settings that offer no strategic guidance? Conversely, we often see low-level implementations where the assumptions inherent in the implementation cascade back up through the big picture and ripple through the whole security architecture: “Well of course for this little widget to run you have to open XYZ firewall ports, disable the sandbox, and send everything in the clear.”
So the challenge in security architecture is clear separation between the views and artifacts for big picture versus practical views, and then working toward making the decisions implicit then consistent across both.
The person who knows fuzzing is likely not the same one who knows Splunk and NAT and not the same person who knows SAML and Kerberos, and making sure they all work cohesively is fundamental to success. A working model is needed. Like the architecture example, the Security DevOps role exists informally in many organizations - its the people who cut across the siloes to get the hard stuff done, but it would not hurt to see a formal Security DevOps role emerge.