NICE viewed from an AppSec guy
I participated in a NICE workshop this week with Chris Schuller of Boeing and Jennifer Oddo of Youngstown State University titled “Creating a Job-Ready Cybersecurity Workforce: Connecting the NICE Framework to Education and Training.” We provided three different perspectives – an educational institution, a commercial training provider, and an enterprise with thousands of professionals who need to build secure products. Following are my thoughts as a provider of enterprise software security training solutions.
The NICE Framework provides an excellent jumpstart for organizations looking to understand and standardize security job functions. It provides a set of building blocks broken down by:
- Categories (7) – A high-level grouping of common cybersecurity functions
- Specialty Areas (33) – Distinct areas of cybersecurity work
- Work Roles (52) – Detailed groupings of cybersecurity work that describe specific tasks
The basic building blocks of NICE are called TKSs (Tasks, Knowledge, and Skills), as illustrated below. They are intended to provide organizations a common language to describe their security work and workforce.
This helps organizations minimize complexity, normalize language, and source appropriate training. Given that titles vary wildly from one organization to another be mindful to focus on the TKSs associated with a work role rather than the title NICE attributes. Teams can use NICE to more effectively groom and develop talent, which leads to reduced risk – ensuring staff meets appropriate skill bars. But to do this, all training stakeholders need to get together to figure out what training is needed for their work roles because they will most certainly differ from how NICE defines them.
NICE is a framework, meaning it doesn’t give you answers – rather, it provides guardrails and guidelines around which to build (or source) your own job descriptions, training, and workforce development program.
While it doesn’t provide tools for staff assessment, it defines the concept of a “competency” as a mechanism for organizations to assess learners. NICE recommends that competencies include a group of associated TKS statements; however, they make it clear that competencies should be “defined via an employer-driven approach.” Essentially, NICE offers TKSs and asks employers to build their own competencies, sharing those competencies with educators & training providers who, in turn, will provide some assessment vehicle.
There are many security disciplines. Security Innovation’s is Software Security (aka Application Security.) Security requires specialization, not just from an individual perspective but from training providers as well. This means organizations may want, and likely need, to go with different vendors depending on the discipline. Standardizing skills development enables better and more effective decisions for staff, businesses, education, and training vendors alike. The result is more secure products for consumers of tech/software.
Building a right-sized training program for your organization
Because NICE focuses on those roles whose primary job is to analyze and defend against cyber attacks, it’s less relevant for technical teams whose primary role is not security (e.g. software development, DevOps, IT operations). For these scenarios, NICE should be augmented with a tiered, prescriptive training approach as similar job functions work in literally dozens of different technologies.
We’ve observed this progression with respect to security skills development in most organizations:
- Awareness – Build a fundamental understanding of high-level security principles that affect those with related charters. The 33 NICE specialty areas are a good place to start, e.g., what does the “Data Administration” team need to know about security?
- Fine-tuning – Once the security principles have been rolled out, you can start going deeper with role-based security training.
- Specializing – For non-security roles, augment your training content that is platform-specific (cloud, mobile), processes-specific (DevOps, agile), programing language-specific (Java, PHP).
The Business Case For Software Security
Considering the objective of frameworks and why NICE tried to remain tech-agnostic, the exclusion of software engineering is a missed opportunity. Software runs the modern enterprise, and insecure or misconfigured software is the primary cause of data breaches. Development teams comprise the highest percentage of technical staff, and within those teams, there are over ten different job functions. There are even sub-disciplines like product security, application security, cloud security, DevSecOps, and more. Chris Schuller of Boeing discussed how his team opted to map their work roles to NICE TKS. Boeing needed to up-level internal talent across all departments (Engineering, IT, Supply Chain, Manufacturing) and all levels (individual contributors, tech fellows, managers, executives). NICE is a good starting point for them, but they had to construct their own combination of TKS for the departments and work roles that NICE does not address (which is most roles on their product and IT teams.)
With today’s emphasis on shifting security left, faster release cycles, and building-security-in, a natural evolution for NICE is addressing software more specifically. When I mentioned this on the panel and identified other roles NICE doesn’t cover, Rodney Peterson, Director of NICE, suggested that perhaps we could build a “Companion Framework.” What a fantastic idea, Rodney! NICE Workforce Framework for Software Teams. No need to get into specific dev methodologies like agile, DevOps, or CI/CD – just cover the roles that exist on Software Teams.
Jim Manico, long time OWASP contributor, trainer, and author, said it best:
“From my experience, all software developers are now security engineers whether they know it, admit it, or do it. Your code is now the security of the organization you work for.”
How Security Innovation leverages NICE
Security Innovation has been offering software security training for over a decade. We’ve evolved from just offering secure coding for developers and into the software ecosystem, which included builders, operators, and defenders of software. We have to make it easy for customers to get the exact training they need to perform their work functions in the technologies they are working in.
We start with the NICE specialty area to understand which specific areas they want to train in. We dig a bit deeper for software developers because oftentimes when clients tell us they want to train their “developers,” they mean all those who define, design, construct, test, deploy, operate, and maintain their software. We break down those job functions, layer in tech stacks, and create specialized learning paths, e.g.:
- Identify specific roles: PM, analysts, architect, developer, engineer, DevOps, Test/QA
- Include technologies: Programming languages, frameworks, deployment platform, etc.
- Needed competency: 100, 200, 300 level organized into learning paths
Every organization has slightly different needs, which is what NICE got right – flexibility. However, core building blocks of role- and tech-specific training are absolutely needed to jumpstart pretty much any type and size organization.
(Sound like something you'd be interested in? Get in touch and we'll chat.)
Bonus Tip:
The OWASP Software Assurance Maturity Model (SAMM) is a natural complement to the NICE Software Development specialty area. It provides a risk-based maturity assessment covering all the major domains of software development and deployment. This can help identify activity gaps and what specific training is needed for the various software roles to be able to conduct them properly.
