Speaker: Jennifer Bayuk
Based on work for Stevens Institute of Technology.
How do professional systems engineers work?
History:
- Mainframe
- physical security (punch cards)
- cables to terminals
- network to workstations (some data moves there & on floppies) *spike in misuse & abuse
- modems and dedicated links to external providers/partners
- added midrange servers (including e-mail)
- added dial-back procedures to modem
- e-mail & other issues begat firewalls
- firewalls begat the “port 80” problem
- modems expanded to the remote access issue
- remote access issue begat multi-factor auth
- then an explosion of midrange begat more malware
- internal infestation from web sites & more e-mail
- added proxy servers
- made anti-virus ubiquitous
- kicked in SSL on web servers that now host critical biz apps
- (VPN sneaks in for vendors & remote access)
- more customers begat identity management
- increasing attacks begat IDS
- formalized “policies” in technical security enforcement devices
- now we have data & access everywhere, begets log management
- data loss begat disk encryption on servers & workstations
- increasingly common app vulns begat WAFs
Reference: Stevens Inst. “systems thinking”
Use systemogram to show what systems are supposed to do (very cool visualization for differing views of “security systems thinking”)
applied that systemogram model to a real world example of Steven’s school computer lab
Shows the “Vee Model” (her diagram is more thorough – GET THE PRESENTATION)
Advantages of this approach include:
- Manage complexity
- Top-down requirements tracing
- Black box modeling
- Logical flow analysis
- Documentation
- Peer review
- Detailed Communication
Must advance and move beyond threat->countermeasure insidious cycle.
Traditional requirements process involves gathering functional requirements, interface definition and system-wide “ilities” – need to get it in before the interface level (high-level “black box”)
The major vulnerabilities are at the functional decompositional level
Many security vulns are introduced at the interface level as well
Unfortunately, it’s usually put at the system-wide level (as they do with availability ,etc)
What Do Security Requiremens Look Like Today?
- Functional – what is necessary for mission assurance
- Nonfunctional: what is necessary for system survival
- V&V: what is necessary to ensure requirements are met
V&V: Verification: did we build it right? Validation: was it built right? (akin to correctness & effectiveness)
There are more similarities than system architects really want to believe or understand.
Much of security metrics are really verification vs validation
Validation Criteria
- content
- face
- criterion
- construct
