Software DLC vs System DLC

jonwinterburn

Hi all,

So with not much time left until I sit the CISSP exam (can't say what day, as that's my superstition!), and after 6 months of study, I'm going through all the concepts that I've either struggled to understand or have understood, but struggle to retain (IPSec, Kerberos, SDLC, Wireless security).

One area that I just don't get is SDLC (software) versus SDLC (system). I fully understand the software version. I don't get the system version. I don't understand WHY the two exist separately of each other. Can someone please explain to me where I would use the System DLC in the real world (where I wouldn't use software DLC instead)? The steps for each are different, although similar. I simply can't commit the steps to memory until I understand the purpose of each. I've read and re-read about each in the AIO and other books, but all I get from the books are the steps - not the reason for the two.

Thanks,

Jon

jonwinterburn

So I've read Eric Conrad's 11th Hour take on this, and this is what he says:

"SDLC is used across the industry, but SDLC focuses on security when used in context of the exam. Think of 'our' SDLC as the 'secure systems development life cycle': the security is implied."

So does that mean I don't need to worry about classic SDLC process (Requirements Gathering, Design, Development/Coding, Testing, Release) and just focus on the secure SDLC process (Initiation, Development/acquisition, Implementation, Operation/maintenance, Disposal)?

philz1982

jonwinterburn wrote: »

Hi all,

So with not much time left until I sit the CISSP exam (can't say what day, as that's my superstition!), and after 6 months of study, I'm going through all the concepts that I've either struggled to understand or have understood, but struggle to retain (IPSec, Kerberos, SDLC, Wireless security).

One area that I just don't get is SDLC (software) versus SDLC (system). I fully understand the software version. I don't get the system version. I don't understand WHY the two exist separately of each other. Can someone please explain to me where I would use the System DLC in the real world (where I wouldn't use software DLC instead)? The steps for each are different, although similar. I simply can't commit the steps to memory until I understand the purpose of each. I've read and re-read about each in the AIO and other books, but all I get from the books are the steps - not the reason for the two.

Thanks,

Jon

So here's the deal. Software is a system and a system is software, but yet they are not the same. Confusing eh? Let me explain.

So I have this software at a hospital that I was working on three weeks ago. From an SDLC perspective the software followed an AGILE DP (Development Process). This means that the concept was mapped out and developed through iterative 3 week periods (some would argue this is SCRUM/AGILE, but whatever). Ok, so if you follow the SDLC. The first, cycle on a new software is what???

You should have been saying planning. So here's the deal, the first hickup/trick on the CISSP realize that new software, that is not replacing old software starts at Planning. On older software, you may have a blend of maintenance/planning for your start phase. Like oh crap, our source code is in .net framework 1 and doesn't support multi-threaded applications, crap we need to recode!

Ok, so moving right along. You move through the phases, planning, analysis, design, implementation, maintenance. From a software perspective.

->: You Plan out your code using stories, use cases, ect. If this an upgrade you look at your past software and find the differences. PLANNING
->: Now you move into analyzing, can I reuse code, does this meet the needs, vet with the Cxx folks, is there a market. Do an In/Out list, what features are in, what features are out? What are sys reqs, what's the environment.
->: Let's build out a UML Model, what's our classes, interfaces, UX prototypes, ect. What do we need to be successful, iterate out until you have a working prototype, then find a test audience and iterate through the Alpha, Beta, to Production code. DESIGN
->: Now we move into implementation, we role out the code, iterate through patching, deploy to the environment, viola IMPLEMENTATION
->: Maintenance, we check our modules, plugins. Are we using modernizr for a web app, does it have a sec hole? Patch that sucka! What about that OpenSSL bug, time to fix our server side WS. This continues until the software becomes antiquated enough that you need to move back into planning.

OK, so why did I tell you this rambling mess of a post?

A system is no different. Don't get caught up in the words. My Operating Room Software, sits on a IIS Web Server on a W2012 Server OS. It uses a variety of Plugins, and has client machines that sit on All-in-One touch screens. They have USB based barcode scanners and Prox Card Readers. All of these pieces comprise a SYSTEM. I still move through the steps though.

->: I plan out my system: What do the Nurses and docs need to do? Who will use it? How will they use it? PLANNING
->: Deep dive into use cases, use those story cards (AGILE/SCRUM), does it make sense? Does it flow? Does it work with business processes? Is the system environment suitable? Network, Servers, IPSEC, ect? ANALYSIS
->: Move into the design, what does the UX need to be? Natural, or Simple? How do they use it, when the walk in to the OR is their left hand or right hand free? How will they touch the screen? Should the screen dim? What colors work well in low light? What kind of traffic? UDP/TCP? Should it be QoS'd? Route through what VLAN? DESIGN
->: Now I need to roll it out. Do I prototype and sandbox? Do I role it out to the production? Do I core code and core system specs and iterate to functionality? How could this fail? Roll out to one OR, check with the client, iterate through then fully deploy to production. Make changes to the system document, train, turnover? IMPLEMENTATION
->: Great, now Chrome V37 has a memory leak, the All-in-One's crash, crap now I need to run TS on the heap, check for memory leaks? Update the Certificates, Test the login, Nurses want different functionality, modularity? Add, features, traffic is getting bogged down by imaging, look into the Switches? Dedicated Pipe, QoS at the Access layer or at the distro? Continue to Patch. MAINTENANCE

Hopefully you can see, the steps are the same. The big difference between software and system are what and who is involved. Software is purely code. System is the, system, all the pieces that comprise a working closed loop.

Hope this helped

-Phil

philz1982

Oh,

And remember, CISSP is about management answers. Don't get caught in the minatue. Think:
1)Life Safety
2)DR/BC
3)Risk
4)Security
5)Governance

All, questions seem to fall into that: What is the best method for x. Why use y development cycle. Ect.

Spin Lock

I too struggled with this issue. Here’s what I came up with after digging into this topic. As always, I’m gonna preface my comments by saying I’m no expert. Just another engineer sharing his view on this topic. No guarantee I have my facts correct.

First, the acronym SDLC should always refer to System Development Life Cycle. I know some folks use it to refer to Software Development, but as you have surmised, that just complicates matters. We’ve got enough crap to memorize for this exam without having to worry about acronyms that have multiple meanings! Plus the NIST SP 800-64 document defines SDLC as SYSTEM DLC, so that’s what I’m going with.

The System Development Life Cycle is a model that was created to help organizations manage the complexity associated with developing “systems”. A system can be an application, a hardware-based appliance (switch, router, IDS), or an IT project (designing and deploying a new data center). The important thing to note here: SDLC provides guidance to anyone who is managing the development of a complex “system”, where the system could be software, hardware, a data center or a client-server based architecture with distributed services running locally and also in the cloud.

And just as the definition of “system” is left wide-open, the term “complexity” is equally as general. If SDLC is meant to help manage system “complexity”, what kids of complexity are we talking about? Well, there is functional complexity – how does a team ensure the final system performs all the operations the customer is expecting? There is financial complexity - how do we design the system within our allocated budget? There is schedule complexity, and human resource complexity. The point is, there are a lot of goals that a system must meet. It is beyond the scope of the CISSP to expect us to be familiar with all the possible goals. However the exam does expect us to understand the SDLC process as it relates to SECURITY. It even tells us to refer to NIST SP 800-64 which covers the Security considerations in the SDLC process. So I would make sure you are at least familiar with this document.

Finally, the software development life cycle. The software DLC is a subset of the SDLC process. If you take the SDLC process as described in NIST SP 800-64 and you customize it such that the “system” being designed is a software application, you get the software development steps described in the exam guides. So eventhough waterfall model is introduced as a software development model, it is really an implementation of SDLC. In fact, the waterfall model was first used to design “systems” that didn’t involve software. It pre-dates software development. I don’t think this is the case for all the models – I can’t see a use for Agile, scrum, XP, etc for systems other than software. So I consider them to be SDLC implementations specific to software.

As for your question about which model you need to be familiar with, the classic SDLC vs the security SDLC. I think you need to be familiar with SDLC as the overall model that helps manage complexities of all types (functional, financial, scheduling) and then really drill down and understand how this model is used to specifically manage security concerns. I can’t recall the source, but one of the documents I read said something like this: “As a CISSP you are not expected to write the code – that’s the job of the software developers. But you would be called upon to provide the development team with guidance on how to make the application secure.” So I read through the SDLC domain with the goal of understanding the SDLC process at a high level and, in much more detail, understanding how to overlay security on top of that process. For example: know when and why to perform a risk assessment, design reviews, threat modeling, coding best practices, static/dynamic analysis, fuzzing, vulnerability assessment and configuration management.

jonwinterburn

Thank you for such a comprehensive, yet simple explanation of how the two are essentially the same. Exactly what I was looking for!

Spin Lock

Sure, glad you found my post useful.

Best of luck on the exam. And remember, make sure to check the least upper bound of your partially ordered set or your security kernel might leak memory and your polymorphic object broker might might fail certification because it wasn't fuzz tested (probably because the QA team and Developers didn't practice separation of duties)!