2014/01/27 15:15 Perri Nejib and Dawn Beyer, “Agile Concepts for Security in SE at Lockheed”, Agile Systems and Systems Engineering Working Group
This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.
INCOSE International Workshop 2014, Torrance, California
Review articles are at:
These authors are writing an essay that hasn’t yet be cleared by Lockheed.
Secure Engineering Assurance Model
Starting working with challenges in security, saw them as the same in engineering in general
Also in agile, since threats change so quality.
Advanced Persistent Threats: backed by nation states, e.g. China and Russia, but they don’t want us to know that they’re in there.
So, agile security is important in this world
- Not just agile principles and practices, it’s about being agile
There are 15 people in Lockheed who have to approve the paper, some layers
Already presented some of the work in the INCOSE security group.
Content of essay is like talking to slides, which can share.
Perri has had to explain why security is part of systems engineering.
- System security engineering is systems engineering applied in a security context.
- Had some things to do that no one else was doing, they fall to the systems engineer.
Agile threat means need agile processes to respond.
Can look at security from cradle to grave
- In proposal
- Development phases
- Operations & Management in Network Operations Centre, have Information Systems Security Analysis
Problems with security engineering in information sharing
- We do a good job of information sharing in intelligence with DoD and talking about threats with competitors
- But not joined into deployment and Operations and Management
- Leaned process by 50%, still complaints of too long, now working on checklists
- Problem if not in process, individuals won’t cost it out, because it’s someone else’s area, but then find new vulnerabilities
- Testers need to surface controls to be done
- If communication not shared immediately, then other vulnerability can be exploited
Question: locus for threats? Where they rise from?
There’s a lot of open source information on threats.
- From counter-intelligence, China and Russia attack contractors
- Hackers can brag about getting into network
- Not seeing red (adversaries) but grey (friendlies) e.g. U.K.
- They don’t want to be noticed, they’ll come in persistently and slowly, and then start getting information
- Vectors are e-mail, USB drives, PDFs
- Security office does a lot of testing of people, to see if they’ll report
- Also insider threats, can’t trust own people: disgruntled employees, someone who is about to leave the company
Not just challenges of cyber threats and cyber intelligence, may be identifying a vendor that has 3 pieces of which 2 are in the U.S. and one is in the Middle East
- Normally a systems engineering wouldn’t red flag that
- A security engineer could say we can’t use that piece
Or particular solution needs to be physically located outside of U.S., need to know there.
Threat working group
- Part of this is supply chain organization
- Internal intelligence
All in the threat working group are sharing knowledge, and it changes rapidly
- e.g. did a trade study, found product A was best, but then with other considerations have to go with product B
Process itself is agile, morphs to needs of user
- Wanted to make sure that the processes weren’t created top-down.
- Piloted with actual processes at Lockheed
- Did get feedback from some “are you crazy”, because threat assessments can be costly
Question: Requirements, changing spec, test integration phase?
Framework, not methodology.
- Shows activities that a security engineer has to perform at certain times of the life cycle.
- e.g. as requirements going on, security engineer does a high level security risk assessment
- These all have to be integrated into a systems engineering, otherwise will overlook security or contradict some other performance
- Customer may call out security as standalone, as certain deliverables to be presented with a solution
- Security architecture and code reviews: not just functional
- When in security, preached test before development, but then how to test “the system must be secure”
- Penetration test
- Vulnerabilities before upgrading
Question: Change management?
- Here’s its so fast, there’s no formal change management
Sharing threats is still a struggle to let information go
- A privilege and control change, cultural
- Need strong requirements: what do you want, a report, machine-to-machine or to a person?
- Requirement part of this is non-process-centric.
- e.g. electrical utilities have FIPS.
- Mapped against ISO and NIST standards: gap in direct modelling of threat sharing
Doesn’t matter where you are in life cycle, could go backwards and forwards.
- e.g. while in design phase, evaluation/audit could request requirements documents
Started a community of practice
- Invited to program managers meeting, if you see any of these words in an RfP, you need a security engineer