cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
JackSussmilch
Newcomer II

Software Security roles

Hi All,
Feel free to correct me on any of the points below. I am interested in what the community has to say about this.

After more than 20 years in the tech sector, architecting, implementing, leading and managing software engineering teams across the entire sdlc and with extensive experience with tying the lines of communication across silos and teams, I decided to formalise my CSec knowledge and obtain a CISSP,CCSP and CSSLP - the last of which is going through accreditation at the moment. I am now working towards the cissp-issmp and then the cissp-issep. So far, whilst there are some new concepts, much of it ties into what I have done previously, so whilst the exams are a bit challenging, I have found my experience with applying the concepts in the real world helps a lot. In fact, I like how the exams are written by people with real world experience - it makes it much less about regurgitation of information and more about knowing and applying the concepts.

To give you an example, whilst I was doing what would now be called DevSecops last century, when I saw devops teams spinning up aws instances paid for using tgeir corporate credit card - bypassing security - I pretty much noped the heck away from these guys.
What I found interesting was how few of my more than 1000 linkedin connections actually had a cissp. I get the impression that many people in the CSec space tend to come more from infrastructure backgrounds - or at least entered into it from that direction.

From my perspective, any organisations biggest csec risks come from, of course people and software - be it poorly configured software or poorly developed software. So I see real scope for more people from sw engineering backgrounds getting much more clued up on all aspects of Cyber security. Heck, I think the solarwinds hack must be a pertinent kick towards this.

And yet, when I look at roles, most Csec roles out there are almost purely infrastructure related, and the roles involving software security tend to be more about pen testing, which whilst being a valuable component, pen testing is still often the "ambulance at the bottom of the cliff" - no offence intended here.

To illustrate this point, I contacted a recruiter who sent through their clients initial request, which was software software, software, and yet the role published only had a cursory mention of software.

Maybe recruiters stripping out sw role requirements because they have given up thinking there are sw people who do take CSec seriously?

Is this the experience other people are finding coming from a software background or am I off base?

4 Replies
Steve-Wilme
Advocate II

The software related roles out there are probably described as assurance roles, rather than specifically software security.  With companies using SAST, DAST and RASP there will be some that think these to be a silver bullet and ignore the requirements, architecture and design aspect altogether.  It's something that certain teams that believe Agile means no design and no documentation play on, so they can crank out quirk and dirty software whilst describing the defects, including lack of adequate security as technical debt.  And so the analogy is interpreted as something that can be repaid long term or rolled over, rather than something which could produce in a breach at any time.  He appropriate lens is risk, not debt.

 

-----------------------------------------------------------
Steve Wilme CISSP-ISSAP, ISSMP MCIIS
JackSussmilch
Newcomer II

Steve,
I agree completely. The divide between software teams and the other essential groups is huge and it works to everyones' detriment. There are some good methods there, but with so many groups trying to imitate others instead of actually understanding the appropriate application of methods to known quantifiable problems, things are really getting distorted imo.
Its interesting to note a contact of mine who wrote papers on RUP with some really good mechanisms to effectively managing risk in software development returned to the industry after a 10 year break and one of his first comments was that it seems effective risk management in sw development doesn't seem to have improved at all. It hasn't. Its actually gotten worse in many respects.
I just watched another seminar on devsecops, and they're making the same misattributions as devops has.
When they go on about an organisation doing 23k releases per day, it's clear that they're conflating functional software changes with data and content changes. Heck, I still have huge problems with even the term devops as the nomenclature ignores all of the other aspects and groups involved in the management of creating and releasing secure softwate efficiently. I can't see a term like reqdevtestsecrelops taking off anytime soon.
And yes, the XP movement was extremely effective in arming up developer centric perspectives. I see it as being more of a reactional ideology. I understand the driver for it as during the previous decades, dev teams were encumbered by processes and tool implementations which were negligently atrocious - for example, a defect process with "only 23 steps and under 60 fields". And yes, it was designed by a committee and yes, they did roll it out globally, so the kickback was inevitable, but the kickback has been damaging in many ways also.
Until we have more real interdisciplinary collaboration, progress will be stifled, imo. But this will require, I think,a separate role definition for bringing this together - I can't see "scrum masters" ever having the expertise, lol.
I am thinking of putting together some form of educational video about the bigger picture, but the kickback from the ideologues might not be worth the drama. It would hardly ever be watched.

AppDefects
Community Champion

What I have found is that you can teach software security engineering principles to a few developers but that you can't always be successfully in teaching it to networking engineers for various reasons. 

 

The big problem with application security today is the move to Agile. Few Fortune 100 companies do it they still are in love with Waterfall. Even CMU SEI endorses it here. In another article which contrasts that approach to Agile is Making Security in a Software Factory

 

TL;DR

 

Application security is at a crossroads:

 

  • Option 1 -- keep trying a waterfall based, expert-driven, siloed approach to security that's slow and expensive and has never delivered much real value.
  • Option 2 -- re-imagine the work of application security so that it can be delivered by a normal software organization as part of delivering great software.
JackSussmilch
Newcomer II

@AppDefects .  You are correct.  Based on my experience, in order for real progress to be made,  people need to think outside of the frameworks and look at the methods and the problems they help solve.  Just as with any basic engineering,  we need to elicitate the problem before looking at the various solutions to the problems.  As an added bonus to this,  this approach not only ensures we don't get confined to the methods of any one particular methodology,  but when done well,  it enables the effective measurement of the efficacy of many of the methods .

 

For more than two decades I have watched as debates raged between "Waterfall" and "Agile",  "RUP vs RAD" or "agile vs XP" and it follows a similar pattern to developers arguing over whether C++ or .Net is the best language.  Of course,  when performed effectively,  each set of methods is best suited to different situations.

 

Unfortunately,  just like all methodologies,  they are most likely to fail at the implementation level.  It's the old saying that "if all you have is a hammer,  everything looks like a nail".  People are most likely to advocate for methods,  tools and processes they are most familiar with and can quite often apply them to the wrong domains.  The software tooling arena is notorious for this.

 

And then there is often a divide between the process expertise and the technologies used to implement the process.  When either team dominates the outcomes are compromised.  One large organisation I remember actually had the process guys and the tooling guys located in separate cities.  In this case,  the process guys dominated and the tooling guys were forced to effectively butcher the capabilities of the tools so it would fit into the Visio diagrams provided.  It works the opposite way as well (more often so) with sporadic tooling implementations pushing out features with no well defined process or alignment.

 

As an example,  I understand Winston Royces' original thesis formalising the Waterfall methodology actually stated that "teams should go through this process multiple times" - or words to that effect. The idea of it being iterative was already there even back in the 1970s.  Unfortunately this is not how it was taught and definitely not how it was attempted to be applied.  In fact,  I would actually say that whilst the waterfall methodology is based on the core premise or hope that requirements will not change,  every substantially large waterfall implementation ends up being iterative as the Change Requests come through.  The question is how is it handled and whether you have the maturity of the processes, supporting systems and personnel capability to manage whatever approach you have.

 

On the other hand,  the Agile camp have focussed more on speed of delivery and feature delivery on the premise that if problems are found they can be addressed rapidly.  Now this can be very effective if you're developing a non safety critical webapp,  but if you're going to be waiting 6 months for UL to test and approve your product for sale,  as an example,  it's a disastrous mentality to have.  Whilst there have been attempts to do Agility at scale,  they have their own issues - not the least of which being how they risk of overloading the architects and in it's purest form,  multifunctional teams running roughshot over Centralised business systems (Databases and Security).

 

Over the decades,  I have always worked to apply the best method to the right problem space.  This can involve some experimentation,  but it does work well.  I have used well known and lesser known methods regardless of their branding.  Heck,  one of the most powerful and effective methods I have applied originated in the Prussian military doctrine of the mid 1800s (Helmuth Moltke the Elder).  This inspired an extremely scalable solution which had managed centralised control with decentralised enablement.

 

Some of the SCM principles I have taught and had my teams teach over the years actually cite configuration Management of Carthaginian ships in the third Punic war.  The concepts are the same,  and having physical examples can be a powerful means of communication.  Obviously with the complexities of modern systems,  the nuances differ,  but the core concepts I have found to be quite stable. 

 

The balances can be achieved when we don't box ourselves into this tribe or that tribe.