ism and its impact on government project delivery
TRANSCRIPT
Information Security ManualWHAT IT IS, AND ITS IMPACT ON PUBLIC SECTOR PROJECT DELIVERY
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”
AGENDA
Who ARE we? What is the ISM? Common Misconceptions Common Issues Issue Resolution Scenario
Q & A
Who are We?OR WHY YOU OUGHT TO LISTEN TO US
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
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
What is the ISM?
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?
Common Misconceptions / Issues
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
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
Common Issues
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
ScenarioDEPARTMENT OF MAGICAL ANOMALIES
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
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
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
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
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?
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?
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?
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
Free resources to help with your ISM Compliance
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
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
Q & A
James Mouat@joflixenhttp://au.linkedin.com/in/jamesmouathttp://james.mouat.net.au/ism/http://james.mouat.net.au/ism/checklist/
Kevin Landale@craftyninjahttp://www.thecraftyandnudge.comhttp://au.linkedin.com/in/landalekevin
Thank You