• Save
Security Access Models
Upcoming SlideShare
Loading in...5
×
 

Security Access Models

on

  • 2,161 views

Presentation about the importance of securing information management systems and a way to achieve this.

Presentation about the importance of securing information management systems and a way to achieve this.

Statistics

Views

Total Views
2,161
Views on SlideShare
2,155
Embed Views
6

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 6

http://www.slideshare.net 5
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Good afternoon everyone, today I’m going to discuss the increasing requirements to gain greater control over the increasing numbers of information management systems within our organisations.

Security Access Models Security Access Models Presentation Transcript

  • Securing Your Agency Importance of Information Security Access Models http://www.flickr.com/photos/ravages/2853378788/
  • Outline
    • Identifying the problem space
    • What, why, when and how of a Security Access Model
  • AS ISO 15489 Requirements
    • … both within an organisation and to external users.
    • … assigning access status to both records and individuals.
    • Indicate who can do what
    • Complement classification
    • Risk management tool
    Access controls…
    • More information
    • =
    • More systems
    • =
    • More points of entry
    • =
    • More access to control
  • The IT vs IM battle
    • Access problems with “techie” implementations
    • “ Organic” development platforms
    • System descriptions that don’t describe anything
    • Database Name – XYZ Correspondence Database
    • Description – Storage of the correspondence for XYZ
    • Job Title/Section/Unit/Location
    • Job Title/Section/Directorate/Unit
    • One job title change
    • One section change
    • Three Directorate changes
  • Information management systems
    • Shared Drives
    • Databases
    • Portals
    • Internet
    • EDRM Systems
    • Intranets
    • Wikis
  • If only…
  • Even in Web2.0
    • http://www.thestandard.com/news/2008/06/10/things-cia-learned-about-implementing-enterprise-wiki
  • Security Access Models
    • What?
    • Why?
    • When?
    • How?
    http://www.flickr.com/photos/29013381@N04/2790170814/
  • Anatomy
      • Identify the system
      • Detail security requirements
      • Provide general policy overview
      • Define the user groupings
      • List the exceptions to the rules
      • Define the system permissions
      • Capture Permission – Group – Folders matrix
  • System
      • System Name and Version
      • Owner/Sponsor
      • Manager and delegates
      • Support provider – include SLA if you have one
      • What the system does
      • What business function(s) it supports
  • Security requirements
      • The level of classification that the system holds (In-Confidence, Protected, Restricted, Secret etc.)
      • Explanation of the access control limitations that are required
  • Policy statements
      • List of the access “rules” for the system
      • Examples:
        • Permissions are not applied against individuals, they can only be allocated against positions or groups
        • Standard users will not be given permission to delete content from the system
  • Definition of groups
      • List of the groups set up inside the system
      • Basic description beside each group in the list to describe the members and intent of that grouping
    • Important to highlight groups that will have limited access and groups that will have higher access
  • Exceptions
      • The exceptions to the “rules” defined in Policy Statements
    • There are always exceptions to the rules, so it is best to capture them before someone tries to correct them
  • Defined permissions
      • List of permissions or “roles” inside the system
      • Description of the access these provide
  • Permission allocations
      • Matrix of permissions
      • Best to have two tables – positions allocated to groups and then group permissions against data
    • Put the people to positions or people to groups mapping in an Appendix as it will change regularly
    • Getting staff to do it prior to implementation
    • Hard to maintain accurately
    Issues
  • Further considerations
    • Staff knowledge
    • Applying the right classification
    • Storing in the right location
    • Not sharing access
  • Presentation by Kylie Dunn [email_address] http://www.flickr.com/photos/jpconstantineau/2121027361/sizes/o/