Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • 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
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Secure by Design - Organizational aspects of security

 
Sheriff
Posts: 14758
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Authors: thanks again for hanging out with us to discuss your book. One thing I missed seeing was a discussion on aspects of designing your organization in a way that promotes security-related thinking and development practices. I was expecting at least a mention of Red Team and Blue Teams in particular but couldn't find any references to either one in the book.

Can you share some thoughts on team and organizational structure as they relate to security practices?

For example, there's the idea of having checks and balances and separation of concerns in an organization. While there are good reasons to have this, it can also sometimes be in conflict with other goals like agility, collaboration, and eliminating organizational silos and handoffs. What are some important considerations for striking a balance here?

BTW, I was happy to see that security-related testing was given a good treatment in the book though.
 
Author
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Junilu

First and foremost: I'm glad to see someone sharing the interest in organizational aspects of security. It is indeed an important aspect in and of itself.

There was a risk that the book would be an evergrowing entity as security is so multifaceted. So, we had to restrict ourselves to things where we could see a clear connection to design - as that is the theme of the book (Secure by Design). That is the really simple explanation why Red/Blue Teams are not even mentioned.

Of course organizational aspects of security could be a book of its own, but we have a few favorite ideas we would like to share.

As we mentioned in the book, it is important that security gets recognized as a first-order concern in and of itself - not as something that should just happen. It is important that product owners understand that "stories" are not just about functionality. Also quality attributes ("non-functional requirements") have their place there - and the security concerns of confidentially, integrity, and availability.

We mention in the book ways to feed such stories into the backlog. One of them is the result of security pen-test. Another is the continuous learning when the team works with the system. We mention "do not forget about security" (title of last chapter) that even though the methodology of Secure by Design aims at giving security as a side benefit of design - it is not enough. You have to pay active thoughts to security from time to time, even if not in every minute and second. So, the team has to learn - attend a security conference, watch YouTube videos, read a book, listen to pods.

One way of our preferred ways of establishing security awareness among the engineers is to start a security forum where each team send a security champion. The purpose of the security champion is to have one developer (coder, tester, analyst, whatever) that pays a little bit more attention to security - still not a full-time sole responsibility. The security champions share experiences in the security forum, and it is also the place where you do actual work that all teams benefit from. For such a forum to become effective the champions need to be able to set aside a significant part of their time. Not just an hour here and there, but rather half a day per week or second week away from the team. Of course, there also needs to be security related work inside the team.

So, active product backlog management including security items on one hand, and security focused work through security champions that share and work via a security forum. There we have two small thoughts on security and organisation.

Yours

  Dan
 
Junilu Lacar
Sheriff
Posts: 14758
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Dan. In one of my recent past roles, I was in fact a security "champion." This was due mostly to my being a lead developer and also being part of a small team that developed and supported tools related to managing security-related intelligence. That company also touted a strong security culture and had official internal training programs related to security. We even had a "Security Ninja" track where we could earn colored belts to signify our awareness and knowledge of security. Ironically, however, the company still had and continues to have security-related issues in their products. In fact, I saw another recent news article about a security flaw that affected customers worldwide. This just goes to show how difficult it is to get security right, especially in large organizations.
 
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!