James Mouat and Kevin Landale provide a common sense approach to utilising the ISM in Government Project Delivery.

1. Information
Security Manual
WHAT IT IS, AND ITS IMPACT ON PUBLIC SECTOR PROJECT DELIVERY

2. How this presentation is going to work….
 We’re pretty open, informal guys
 Everything in this talk is NOT CLASSIFIED and this information is freely
available to the public on the Internet
 If you want to say something – Raise your hand and stop us! Speak Up!
 We will be talking about “Common Sense”

3. AGENDA
 Who ARE we?
 What is the ISM?
 Common Misconceptions
 Common Issues
 Issue Resolution
 Scenario
 Q & A

4. Who are We?
OR WHY YOU OUGHT TO LISTEN TO US

5.  Wears a lot of hats (literally and figuratively);
 Career is focused on Information Security, Policy and
Compliance Management;
 Background in Systems and Networking;
 Active in several local InfoSec communities;
 Regularly attends special interest groups and
conferences such as Ruxcon, SIG, ACSC and ACS;
 Working on several ISM Projects on the side;
 Works on a multitude of private engineering projects;
 Works as a Visual-Jockey for nightclubs and festivals;
 Runs an FM Radio Station;
 All of the above WHILE renovating his house.
James Mouat

6.  Doesn’t like Hats, but tends to figuratively wear a fair
few;
 Career is focused on Tech Consulting, Strategy and
Project Management;
 Background in Networking, Business Analysis and Web
Development;
 Active in several local technology-related communities;
 Regularly attends events by the ACS, Canberra
Innovation Network, UNAA, ISACA, IIBA, etc.;
 Working as a casual tutor and mentor at the ANU;
 Working on a few side projects;
 Works as a photographer and blogger;
 Runs a blog;
 All of the above WHILE playing video games and
reading manga.
Kevin Landale

7. What is the ISM?

8.  The Information Security Manual (ISM) is a publication by the Australian
Signals Directorate (ASD) as the standard which governs Information
Security of Government Information Technology Systems.
 It was originally called ACSI 33 until 2005, when it was renamed as the
Information Security Manual, or ISM.
 Updated and published on an Annual basis.
 The current edition was release in April 2015, and consists of 932 controls.
 Contains guidance for Unclassified DLM, Protected, Confidential, Secret
and TOP SECRET classifications.
What is the ISM?

9. Common Misconceptions / Issues

10.  IT Security are far too draconian! I want access to
Facebook/Instagram/Snapchat !!!
 IT Security isn’t important to this project. We’ll worry
about it later!
 The IT Security Approvals process for our system is too
hard and takes too long! The IT Security
team/branch take forever!
Common Misconceptions

11.  Project Cost blow outs
 Project Schedule blow outs
 Inadequate internal skilled resources
 Inadequate understanding of the role of the ISM as a
compliance tool
Common Issues

12. Common Issues

13.  Here are some project phases and where security
advice will help avoid the issues outlined earlier:
 Scoping Phase
 Assists in defining what technical concerns may affect this project
 Design Phase
 Where required, can play a pivotal role in designing out potential
risks
 Testing
 Assess if effectiveness of the technical implementation and if the
scoped security controls have been met
 Operation
 Monitoring the ongoing operation of, and/or response to any
security concerns with the system in use, over it’s lifetime.
Simple Manner on avoiding Issues

14. Scenario
DEPARTMENT OF MAGICAL ANOMALIES

15.  Director John Smith, head of the Division of New
Applications and Public Interactions in the
Department of Magical Anomalies, has been asked
to implement a new cloud-based application to
allow the public to report about new magical
anomalies.
 John starts by creating a project team that consists
of a Project Manager, Business Analyst, Technical
Lead, Architect, etc.
 The team decide that there aren’t enough skilled
resources internally to handle some of the more
technical or complex tasks, so they go and hire
consultants, etc.
Scenario

16.  The Project Plan is created and sent to the Executive
for sign-off. The high level plan states that security
signoff and testing is done towards the tail-end of the
project as a matter of process.
 The project ticks along for over 10 months. Normal
development and other project issues crop up
occasionally, but the team resolve them in due
course. Still, no real thought or foresight given to
security considerations.
 As per Department Change requirements, the project
team start to undertake compliance requirements
towards the end prior to getting the application live
and in production.
Scenario

17.  Project team talk to their IT Security division in order to get security
sign-off…….
 They fail.
 Lots of holes, lots of significant security compliance issues.
 No real protection of citizen data. Brings about further questions on
legal obligations of privacy, confidentiality and data sovereignty.
 No protection against basic attacks such as SQL Injections, etc.
 Cost of implementing all these updates and fixes
= 3 months and at roughly $500,000 per month in resource costs
Scenario

18.  Executives decide to push ahead with the project. Approve
additional time, resources and funding on the proviso that
Security specialists are brought in to assist in ensuring
compliance and best practice.
 Ultimately, the project is considered a success. Despite
taking 8 months longer than planned, and a budget over-
run of over $2.5 million.
* Numbers are just an estimate, but are severely below real world examples
that we’ve seen.
Scenario

19.  The easy answer?
Engage with Security personnel from the start – They are valuable
resource
 While its easy enough to state the obvious in hindsight, the controls
outlined in the ISM help projects in avoiding this scenario.
 Government Agencies are required to address the controls within the
ISM for every system and for the agency as a whole.
 Engaging with Security personnel can raise awareness of other risks
relevant to your project early in the project, this will help reduce the risk
of compliance failure. For example cloud computing requirements:
http://www.asd.gov.au/publications/protect/cloud_computing_security_considerations.htm
Scenario – Resolution?

20.  By engaging with security earlier, business or project teams can
scope out security requirements.
 Security Requirements can then be utilised as part of the
design/development process.
 And, if required, those requirements can help engage with
Solution Providers and/or Specialists.
 Planning becomes less risky, your specifications write themselves,
and in turn make Executives happier as the risk of non-
compliance gets reduced.
Scenario – Resolution?

21.  Engineers keeping security controls in mind when developing
the solution can significantly reduce the need for refactoring
 If the system needs to obtain accreditation, the system will be
assessed for non-compliances and any residual risks after
implementing controls.
 Project Executives can make an informed business decision
based on residual risk, and any treatments applied.
 Organisational IT maturity as a whole will be strengthened.
Scenario – Resolution?

22.  The Information Security Manual is an enabler – NOT an inhibitor.
 Project Success is dependant on a variety of factors, almost ALL
of them important.
 Just don’t forget about Security!
 Early engagement with Security saves a lot of time and money.
 Security Guys are friendly and don’t bite!!
 …
 Profit?
Recap

23. Free resources to help with your
ISM Compliance

24.  GRC and ISM Project pages.
 Key resource:
 Up-to-date HTML versions of the ISM;
 Fully referenced navigation links for the ISM;
 Breakdown of ISM document format;
 Fully self contained, portable HTML file with all images (less than
2Mb); and
 All grammar and mistakes (hopefully) fixed.
Some ISM Resources

25.  And as a special announcement, at the ACS Conference:
 A free-to-use, configurable ISM Checklist
 Scope controls applicable to your project
 Contributes to Requirements and Design
 Record your compliance and evidence statements
 Input for Security Accreditation or Audit Processes
Some ISM Resources

26. Q & A

27. James Mouat
@joflixen
http://au.linkedin.com/in/jamesmouat
http://james.mouat.net.au/ism/
http://james.mouat.net.au/ism/checklist/
Kevin Landale
@craftyninja
http://www.thecraftyandnudge.com
http://au.linkedin.com/in/landalekevin
Thank You