• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Security program: roles and responsibilities of the developers

 
Sheriff
Posts: 15995
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeremy,

I've been looking through your book's table of contents on Amazon and I couldn't really tell if you spent much time discussing the roles and responsibilities developers have in an IT security program. Chapter 6 - The People Problem and Chapter 7 - Assigning Accountability looked the most promising but I didn't see any subheadings that hinted at calling out developers on the things they needed to do.

I work for a large Silicon Valley tech company and my team supports the Security Research and Operations group. We are active in our company's security advocacy grassroots community and special interest group. We have a core of people who are expert to knowledgeable in the domain but it is by far a very small percentage of the entire company-wide development population worldwide. Sometimes it seems like a battle we can't win, what with developers constantly rotating in and out of teams, falling under heavy schedule pressure to get things done and deliver to production, a security review process that is probably porous at best, and a general lack of, from what I've seen at least, an awareness of good security-related development practices.

Our team likes to remind others is that good quality code is easier to secure and you need to build security in from the start, not try to add it on later. The first part about good quality code is the battle front where I always seem to end up fighting. It's rough and one person against many is just not something that's sustainable, no matter how good you are or how much you try to teach people the right way to do things.

I'm just kind of venting here, but I guess my question to you is: From what you've seen in your engagements, what percentage of the developer populations do you find generally clueless about security and what kind of strategies have seen that have helped gain some inroads towards a better security culture among developers? Also, what part of your book, if any, do you discuss these kinds of things?
 
Author
Posts: 6
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu,

Everyone has a role in security and we talk about that in the Assigning Accountability section. I also used Secure Software Design as an example of a process that has worked to make software more secure and a concept we could apply to secure business process design. It sounds to me that the problem you are facing is more related to an organizational commitment to security though. If delivering a product on time is allowed to be used as an excuse to deliver a poor product with significant security flaws, the problem doesn't necessarily lie with the developers, but with the business leaders that allow those things to happen.

There are significant sections of the book that could help you build a business case in order to strengthen the organizational commitment to security by defining the risks associated with building flawed code that has security gaps. Like many problems in security, the solution needs to start with the organization understanding why it is important and committing the organization in a meaningful way to solving these challenges.

It sounds like there is a symbolic commitment through the creation of the security advocacy group, but its important for the organization to follow through by allowing your team to develop a code review process that ensures the best practices you are trying to share with the developers are adhered to. Generally, the only way that happens is to get the business leaders' attention by quantifying risk and presenting a mitigation strategy that can tangibly reduce their risk exposure. In my opinion, its as much about communicating security concepts in business terms as it is about specific tactical strategies to increase your security posture.
 
Junilu Lacar
Sheriff
Posts: 15995
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your response, Jeremy.

It sounds to me that the problem you are facing is more related to an organizational commitment to security though. If delivering a product on time is allowed to be used as an excuse to deliver a poor product with significant security flaws, the problem doesn't necessarily lie with the developers, but with the business leaders that allow those things to happen.


Therein lies the rub. Talk about security actually always seems to come from the top business leaders. From what I've seen over the years, they say all the right things that you'd think would encourage a strong security culture to develop and thrive. They even show a lot of support and give backing and funding for security-related initiatives like a company-wide education and certification track. That program was even given a geeky name "(Our Company) Security Ninja Certification," ostensibly to make it attractive to developers. In keeping with the program name's theme, people who signed up and went through the training videos and passed the assessments were awarded colored "belt" certifications starting from white belt all the way up to black belt.

We have numerous security-related offerings coming out of the learning and development center and there never seems a lack of demand for them.

Yet, I still see many developers writing awful and unsafe code. Like I said, a high turnover rate is one factor that muddies the waters. Too much red tape in the security review process is also a big turnoff. Guidance on security practices is spotty and confusing at best, contradicting at worst. I've even had to suggest corrections to official IT documentation on how to configure web apps being migrated to a new virtual platform because the instructions they gave doubled the exposure and potential for compromise of database passwords.

So, my biggest gripe is that although we're not lacking in support and education opportunities, the development community is big on theory but sorely lacking in execution. Our team tries to help guide others and we try to set good examples but it seems to me that our message just gets lost in the shuffle of the day-to-day business as usual dealings.

One idea I've been kind of mulling over is something similar to Chaos Monkey, except this would be a Security Chaos Monkey. If you could let loose some kind of agent bot in your network and forced people to deal with security issues in their apps, maybe that would light a fire under them. The downside to that is it's not an idea that goes over well with risk-averse management and certainly will get a lot of resistance from groups like the company's InfoSec team, the Customer Support teams, and those teams who deep down in their heart of hearts know that they would be exposed in a minute by Security Chaos Monkey. So that idea will probably never even get off the drawing board.

Have you seen any other ways people tried to force development's hand to address security issues more seriously and with more of a sense of urgency?

Edit: That is, besides regular security audits, which our company kind of has. I say "kind of" because it's about every two to four years that I've gotten told to get ready for a security audit and all it really involves is running an automated vulnerability testing tool against the app in a non-production environment. You get the usual issues reported, like problems that a little fuzzing can show, exception stack traces showing up in the UI or being embedded in the HTML source, CSRF issues, SQL injection issues, but nothing that really needs a few days of profiling and serious prodding and prying, at least as far as I've experienced in over 10 years with this company.
 
Jeremy Wittkop
Author
Posts: 6
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Have you seen any other ways people tried to force development's hand to address security issues more seriously and with more of a sense of urgency?



While I like the idea of letting loose a security Chaos Monkey you've rightly stated that would likely be frowned upon due to the disruption it could cause. One less intrusive method you could use is to do a security code review of all code before it is considered in production. Then developers could be given a score based on how well their code was written over time. If this was part of the process the code would not only be corrected, but the developers would have a metric that measures the quality of their work.
 
Junilu Lacar
Sheriff
Posts: 15995
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jeremy Wittkop wrote:While I like the idea of letting loose a security Chaos Monkey you've rightly stated that would likely be frowned upon due to the disruption it could cause. One less intrusive method you could use...


This is why I like bouncing crazy ideas off of other people, it lets me think of ways I can maybe work around obstacles. Who says Security Chaos Monkey has to go right into production, right? What if we just let him loose in a controlled, non-production environment to start with? Then we can work the kinks out, get apps up to snuff, at least in non-prod. Then when we're comfortable enough, we might try A/B testing or doing Blue-Green deployments and letting SecChaosMonkey loose there. Virtualization can give you even more safety nets.

Like I mentioned before, the problem I find with security reviews/audits is that there's just too much red tape and too little that goes beyond what you can check through automation. Getting a security review engagement involves a bunch of emails, prep meetings, and the risk of having your already delayed deployment pushed out even more. I think changing the security culture, as with all culture changes, really boils down to a slow, deliberate, and incremental change. An evolution rather than a revolution.

Thanks for sharing your thoughts and good luck with your book.
 
Jeremy Wittkop
Author
Posts: 6
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank You!
 
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic