This document provides an overview of security awareness training topics and best practices. It discusses designing training to explain security policies, show practical threats, and empower employees to act as security sensors. Topics covered include corporate policies, regulatory compliance, social engineering, business continuity, emergency response, data handling, personnel security, and physical security. It also provides guidance on teaching policy importance, addressing employee questions, and identifying security risks. Suggested awareness activities include formal training, posters, walkthroughs, and security recognition events. The document emphasizes consistent security metrics, bridging technical and executive perspectives, strategic planning, and annual program reviews.

1. CISSP Training
Pages 566-631
Tim Jensen
StaridLabs

2. Security Awareness Training
●Designed to tell why a policy exists
●Show practical examples and ways to identify
threats
●Turn employees into human security sensors

3. Topics
● Corporate security policies
● Organization's security program
● Regulatory compliance requirements for the
organization
● Social Engineering
● Business continuity
● Disaster Recovery

4. Topics Cont'd
● Emergency Management (hazmat, biohaz, etc)
● Security incident response
● Data classification
● Information labeling and handling
● Personnel security, safety, and soundness
● Physical Security

5. Topics Still Cont'd
● Appropriate computing resource use
● Proper care and handling of security
credentials (usernames, passwords)
● Risk assessment
● Accidents, errors, or omissions

6. Teaching why policy is necessary
● Show real world examples of security failures
that could have been fixed with policy
● Security teams identify risks to the company
and create policies to mitigate just the risks
present. Without policy every risk would have
mitigation even if the risk didn't apply to the
company/department

7. Why are security policies important
● The end goal of security policies is to
protect:
● The organization
● The employees
● The Assets of the company
● (It's customers when possible)

8. Questions to answer in training
● How does all this security stuff affect my
job at the company?
● Do I have to do it?
● If I don't do it, what are you going to do?
● All this security crap is just going to
waste time and make my job harder!

9. What should I be looking for?

12. Awareness Activities
● Formal training courses
● Posters
● Business unit walk throughs
● Security articles/reminders on intranet
● Appointment of a 'security awareness mentor'
● Security Awareness Day – activies, prizes, recognition for winners
● Sponsor event with security organization (ISSA, ISACA, SANS, ISC2, Infragard, etc)
● Provide trinkets for the users within the organization that support security
management principles
● Promote Security Awareness Week/month
● Provide security reference materials to employees (books, videos, websites)

13. Job Training
● Employees should be professionally trained
on the systems/processes they manage.
● Lack of training leads to misconfigurations or
process gaps which can lead to compromise
● It's the sign of a good employee to self learn.
It's the sign of bad management to blindly
trust that the employee is doing so.
● Vendor neutral vs vendor certifications

15. Performance Metrics
● Consistent metrics allow for the
identification of security gaps, identify is
process improvements helped or hurt,
and identify non-compliance
● Can be walkthroughs, quizes, or etc

16. Managing the Security Function
IS Security Officers
● The Information Security Officer is accountable for ensuring the
protection of all of the business information assets from intentional
and unintentional loss, disclosure, alteration, destruction, and
unavailability.
● The security officer typically doesn't have the resources available to
perform all of these functions and must depend on involvement from
other departments/individuals
● Must keep up with emerging technologies and risks
● Security officers often operate CIRT teams
● Provides the leadership for the information security awareness
program by ensuring that the program is delivered in a meaningful,
understandable way to the intended audience.

17. Bridging IT with Executives
● IS Security Officers translate threats based
on configuration/technoligies into:
● What is the real perceived threat?
● What is the risk (impact/probability)
● What is the cost of the safeguard?
● What will be the residual risk?
● How long will the project take (time, money,
people, systems)

18. Reporting
● Security officer should report as high in
the organization as possible to:
● Maintain visibility of the importance of
security
● Limit the distortion or inaccurate translation
of the message

19. Budget
● Security maintains it's own budget as
well as ensures each applicable
department's budget contains funds for
security training/remediation

20. Work Metrics
● Automated metric systems should be implimented to rate the
day to day security and long term trends.
● Helpdesk tickets/hour/day
● Inbound email/hour/day
● Outbound email/hour/day
● Inbound connections at border firewall
– Packets dropped at border firewall
– Packets dropped at internal firewall
● Employee hours spent on compliance reporting
● Report metrics – how effective is each report? Has it ever caught
anything?

22. Interdepartmental resources
● Buy doughnuts for:
● System Admins
● Database Admins
● Network Admins
● Privacy Officers
● Compliance Officers
● Legal
● Law Enforcement
● QA testers
● Helpdesk
● Budget Officers
● Procurement Specialists
● Business Analysts
● Administrative Professionals
● Enterprise Architects
● Software Developers

23. Strategic Planning
● Make 3-5 year plans
● Review annually or before

24. Tactical Plans
● 6-18 month plans for specific purposes:
reducing vulnerabilities, etc

25. Review Security Program
● Anaully review security program for
completeness and to identify gaps

26. Domain 4
Software Development Security
Jem Jensen
StaridLabs

27. Overview
● Planning, programming, and management of
software systems
● Includes both operating systems and
applications
● Software is layered, kind of like networking
● Hardware, drivers, OS, utilities and applications

28. Software Development Life Cycle
● SDLC is is project management process
used to plan, execute, and control a
software development project
● Can differ from project to project
● Specific model should best fit the project

29. Basic SDLC Phases
● Project initiation and planning
● Functional requirements definition
● System design specifications
● Development and implementation
● Documentation and common program controls
● Acceptance
● Testing and evaluation control
● Transition to production

30. Project initiation and planning
● Vision, goal
● Proposed technical solution
● Documentation: charter, scope
● Include objectives, strategy, costs, time
estimates, milestones
● Usually ends with management signoff on
charter and/or scope

31. Project initiation and planning
● Security professional mental checklist:
● Is particular info sensitive? (alone or together)
● Has info owner determined the info value?
● Classifications/Categories?
● Is there a risk of sensitive info exposure?
● Will data be transmitted or stored in public?
● Are controlled areas required?
● What systems interconnect with this?
● How will this affect the org culture?
● Could the company become dependent upon it?

32. Functional requirements definition
● Define end-user needs
● Formalize security requirements
● Often rolled-into project initiation phase
for small projects

33. System design specifications
● Design:
● System architecture
● System outputs
● System interface
● Security features
● Generally based on over-all architecture
for the company

34. Development and implementation
● Generate:
● Source code
● Test cases
● Perform unit tests and functional tests
● Perform vulnerability analysis on code

35. Documentation and common
program controls
● Controls for editing data within the
program
● What types of logging the program does
● How program versions should be stored
● Tests and integrity checks

36. Acceptance
● Ideally, an independent group develops
test data and tests the code
● Should simulate live environment for
good tests
● Ensure the application meets security
requirements and specifications

37. Testing and Evaluation Controls
● Test data should include:
● Data at the ends of acceptable ranges
● Data beyond acceptable bounds
● Various data points between acceptable range
● Random data
● Data validations – review data before and after each
test to ensure data has not been changed
inadvertently
● Bounds checking

38. Testing and Evaluation Controls
● Never use production data
● Sanitize test data
● Test all changes
● Management should be informed and
sign off on testing results

39. Transition to Production
● Train new users
● Implement the system
● Installation
● Data conversions (if needed)
● Parallel operations (to reduce disruption)

40. Revisions
● Regular evaluation and audits
● Should incorporate security planning to
avoid future problems
● Document failures
● Helps to justify future enhancements

41. Maturity Models
● CMM
● Capability Maturity Model
● Framework to product higher quality
software products
● Continual optimization of processes
● ISO 9000?

42. Operation and Maintenance
● Monitor performance of the system
● Detect defects and weaknesses
● Verify changes don't impact existing
functionality or circumvent security
measures

43. Change Management
● Track changes in software and systems to
prevent unintended or unauthorized changes
● Should be a formal cycle with planning,
approval, testing, and documentation
● Patch management
● Should include testing and rollback features