PROTECTION & SECURITY
ISO/IEC 27001:2013, 27017:2015

The objective of the ISO/IEC 27001 standard is to "provide requirements for establishing, implementing, maintaining and continuously improving an Information Security Management System (ISMS)".

ISO/IEC 27017 is a supplementary standard and is a "Code of practice for information security controls based on ISO/IEC 27002 for cloud services" - it adds more definition to each of the  sections covered in 27001/2 for cloud services providers (ibCom) and also customers of ibCom.

Key measures ibCom uses to control risk are:

  • the automation of the mydigitalstructure platform service by using machines and the minimal use of humans in the delivery of the service.

  • after 15 years of development, not making any functional changes to the platform and thus not introducing new internally created risks.  The only changes to the platform are measures to control externally created risks that relate to security maintenance, which is shared with Amazon Web Services.


More about compliance

View our ISO 27001 & 27017 certification

STATEMENT OF APPLICABILITY

ibCom management attest that following controls are in place in regards to risks relating to confidentiality, integrity and availability of customer data stored on the ibCom mydigitalstructure platform using isolated/dedicated services.

Mark Byers
Chief Risk Officer

ibCom employee accessing information The ibCom platform is run by "machines" within the AWS service, with very little human access - only afewlong term highly qualified employees have access.

Being employeed by ibCom does not inherently give an employee access.

If an employee that has not yet been employed by ibCom for one (1) year requires operational access then they must have at least one years experience with an equivalent well-proven provider similar to ibCom.

All employees are bound by confidentiality / non-disclosure agreements.

Employee Appropriateness All employees have a minimum of 15 years industry experience and are tertiary qualified.

ISO/IEC 27001:2013:Appendix A; ISO/IEC 27002; ISO/IEC27017:
  RISK CONTROL
  INFORMATION SECURITY POLICIES
Management direction for information security
 
5.1.1 Policies for information security Part of the employment contract, covering: access to customer data, communication with users on change and data breaches.
5.1.2 Review of the policies for information security Monthly review and re-distribution.
  ORGANISATION OF INFORMATION SECURITY
Internal organisation
 
6.1.1 Information security roles and responsibilities ibCom's Chief Risk Officer (CRO) controls all roles and communicates roles and responsibilities to customers, service providers and suppliers, as required.
6.1.2 Segregation of duties  Only operational employees have access to data.
6.1.3 Contact with authorities Responsibility of CRO to communicate with authorities and also make customers aware of the geographical location of their data.
6.1.4 Contact with special interest groups. Responsibility of CRO.
6.1.5 Information security in project management All projects relating to a potential change in the platform have information security as a first class citizen.
  Mobile devices & teleworking 
6.2.1 Mobile device policy All access to AWS infrastructure on a mobile device is also protected via 2 factor authentication and/or IP address restrictions.
6.2.2 Teleworking No data is stored at teleworking sites.
  Shared roles and responsibilities within a cloud computing environment 
6.3.1 Shared roles and responsibilities within a cloud computing environment Documented
  HUMAN RESOURCE SECURITY
Prior to employment
 
7.1.1 Screening As its first measure, ibCom uses very few employees that have access to customer data.  To get access to customer data an employee must have a minimum of one (1) years experience with ibCom or an equivalent well proven service.
7.1.2 Terms and conditions of employment Information security is at the heart of the ibCom employment contract - including post employment.
  During employment 
7.2.1 Management responsibilities Any breach by an ibCom employee in regards to information security results in immediate termination.
7.2.2 Information security awareness, education & training All employees and contractors will have appropriate industry qualifications or experience and are constantly made aware of information security policies - it is a core value of ibCom.  Employees and contractors are aware, educated and trained in protection of customer data, including derived data.
7.2.3 Disciplinary process Any breach by an ibCom employee in regards to information security results in immediate termination.
  Termination & change of employment 
7.3.1 Termination of change of employment responsibilities User access roles are effected immediately and employee obligations are re-communicated.
  ASSET MANAGEMENT
Responsibility for assets
8.1.1 Inventory of assets All core customer data management assets are managed contractually within AWS, this includes derived customer data. All ibCom assets used to access AWS or other operational administrative services are registered and maintained.
8.1.2 Ownership of assets All assets relating to the platform are owned by ibCom operations and the CRO.
8.1.3 Acceptable use of assets All ibCom assets are clearly identified and linked to the employees role. 
8.1.4 Return of assets Once an employee no longer has a role within ibCom, assets are automatically returned to the direct responsibility of the CRO.
8.1.5 Removal of cloud service customer assets No physical customers assets are stored on site. Customer data assets can be extracted by the customer at anytime using standard mydigitalstructure functionality.
  Information classification 
8.2.1 Classification of information All information is classified based on zone: lab (private), operations (private) & engagement (public)
8.2.2 Labelling of information Documented 
8,2.3 Handling of assets Documented
  Media handling 
8.3.1 Management of removable media Removable media is not allowed on operational assets.
8.3.2 Disposal of media Not applicable
8.3.3 Physical media transfer Not applicable
  Business requirements of access control 
9.1.1 Access control policy Information is controlled within AWS and mydigitalstructure using inherent access control functionality.
9.1.2 Access to networks & network services All key information is stored in internet based secure stores, using encrypted access protocols - no measures needed to control this risk.
  ACCESS CONTROL
User access management
 
9.2.1 User registration & de-registration Information is controlled within AWS and mydigitalstructure using inherent access control functionality.  Customers can self-register and self-deregister using the documented REGISTER and SETUP endpoints.
9.2.2 User access provisioning Internal user provisioning can only be done by the directors of ibCom.  Customers can self-manage their own users using the SETUP endpoint.
9.2.3 Management of privileged access rights Internal privileged rights can only be assigned by the directors of ibCom. Customer can manage all privileged access rights, including multi-factor authentication.
9.2.4 Management of secret authentication information of users Internal users can only be managed by the directors of ibCom.  Customer can manage all secret authentication information.
9.2.5 Review of user access rights Reviewed monthly.
9.2.6 Removal of adjustment of access rights As soon as an employee's role is changed, so are their access rights.  They are removed before the employee is notified.
  User responsibilities 
9.3.1 Use of secret authentication information  All employee's are aware of restrictions on the use of secret information.
  System & application access control 
9.4.1 Information access restriction All platform level access is controlled by AWS & ibCom using mydigitalstructure access control functionality. Customers can control all access to their data using mydigitalstructure access control functionality.
9.4.2 Secure log-on procedures  All information is protected by secure log-on procedures.
9.4.3 Password management system All passwords have industry standard minimum lengths/strengths and 2nd factor is used.
9.4.4 Use of privileged utility programs  There are no privileged utility programs.
9.4.5 Access control to program source code  All access to all source code is highly restricted.
  Access control of cloud service customer data in shared virtual environment 
9.5.1 Segregation in virtual computing environments The mydigitalstructure core security functionality ensures are data is segregated.
9.5.2 Virtual machine hardening Virtual machines that form part of the infrastructure supporting mydigitalstructure are hardened to meet standard security best practices.
  CRYPTOGRAPHY
Cryptographic controls
 
10.1.1 Policy on the user of cryptographic controls ibCom uses cryptography to protect sensitive data.  Customers can also protect their data using mydigitalstructure cryptography functionality - see documention at mydigitalstructure.com/protect_cryptography.
10.1.2 Key management Documented
  PHYSICAL & ENVIRONMENTAL SECURITY
Secure areas
 
11.1.1 Physical security perimeter Refer AWS security compliance
11.1.2 Physical entry controls Refer AWS security compliance
11.1.3 Securing offices, rooms & facilitates Refer AWS security compliance
11.1.4 Protecting against external and environmental threats Refer AWS security compliance
11.1.5 Working in secure areas Refer AWS security compliance 
11.1.6 Delivery & loading areas Refer AWS security compliance
  Equipment 
11.2.1 Equipment siting & protection Refer AWS security compliance
11.2.2 Supporting utilities  Refer AWS security compliance
11.2.3 Cabling security Refer AWS security compliance
11.2.4 Equipment maintenance Refer AWS security compliance
11.2.5 Removal of assets Refer AWS security compliance
11.2.6 Security of equipment & assets off-premises Refer AWS security compliance
11.2.7 Secure disposal or reuse of equipment  All customer data is terminated 60 days after account closure.
11.2.8 Unattended user equipment Refer AWS security compliance
11.2.9 Clear desk and clear screen policy Refer AWS security compliance
  OPERATIONS SECURITY
Operational procedures & responsibilities
 
12.1.1 Documented operating procedures Documented 
12.1.2 Change management All change management is tightly controlled and communciated to customers at mydigitalstructure.com/updates
12.1.3 Capacity management ibCom uses the inherent scalability and monitoring in AWS Infrastructure as a Service to ensure enough resources are always present.
12.1.4 Separation of development, testing & operational environments. The lab and operational zones are procedurally separated.
12.1.5 Administrator's operational security Documented and available on request.
  Protection from malware 
12.2.1 Controls against malware All employees are aware of the issues associated with malware and scanning software is used.
  Backup 
12.3.1 Information backup All information is backed up and restore procedures are constantly being tested.  Users can use mydigitalstructure functionality to build business continuity mechanisms, as documented at mydigitalstructure.com/gettingstarted_continuity.
  Logging & monitoring 
12.4.1 Event logging All events/actions on information are logged and reviewed.  Customers can access logged information using the ADMIN endpoint.
12.4.2 Protection of log information  All logs are secured.
12.4.3 Administrator & operator logs As per 12.4.1
12.4.4 Clock synchronisation All information is stored in a single time zone. Customers can set their timezone and all system date data is then presented in that timezone.
12.4.5 Monitoring of Cloud Services All endpoint interactions are logged and available to customers.
  Control of operational software 
12.5.1 Installation of software on operational systems Instances are re-imaged once a well-proven instance has been fully tested.
  Technical vulnerability management 
12.6.1 Management of technical vulnerabilities Documented
12.6.2 Restrictions on software installation Documented
  Information systems audit considerations 
12.7.1 Information systems audit controls All verification process are carefully controlled and use "mirror" images.
  COMMUNICATIONS SECURITY
Network security management

13.1.1 Network controls All networks are protected using firewalls.  Refer AWS security compliance
13.1.2 Security of network services Refer AWS security compliance
13.1.3 Segregation in networks All ibCom zones (lab, operations, engagement) use isolated networks.  Customer data held in the operations zone are protected by isolated services.
13.1.4 Alignment of security management for virtual and physical networks All access control is via the centralised mydigitalstructure security system, ensuring all layers are matching.
  Information transfer  
13.2.1 Information transfer policies & procedures Refer AWS security compliance
13.2.2 Agreements on information transfer All information is secured by encryption over the wire.
13.2.3 Electronic messaging All highly sensitive information can be secure using the operations@ibcom.biz PGP public key.
13.2.4 Confidentiality or non-disclosure agreements Confidentiality and non-disclosure is default in any engagement with ibCom.
  SYSTEM ACQUISITION, DEVELOPMENT & MAINTENANCE
Security requirements of information systems
 
14.1.1 Information security requirements analysis & specification Documented at mydigitalstructure.com/protect.
14.1.2 Securing application services on public networks Documented 
14.1.3 Protecting application services transactions All transactions are encrypted with SSL and DH based perfect forward security.
  Security in development & support processes 
14.2.1 Secure development policy Documentation available on request.
14.2.2 System change control procedures  Documented.  Changes are minimal.  There is a clear separation between the lab zone and the operational zone.
14.2.3 Technical review of applications after operating platform changes Documented
14.2.4 Restrictions on changes to software All changes are discouraged and strictly controlled.
14.2.5 Secure system engineering principles Using of MVC and separation-of-concerns, combined with a "kernel" mode and "user" mode allow for security zoning, more...
14.2.6 Secure development environment The development environment (lab zone) uses the same protocols as the production environment (operations zone).
14.2.7 Outsourced security testing There is no outsourced development within the ibCom layer.
14.2.9 System acceptance testing Documented
  Test data 
14.3.1 Protection of test data Test data is protected under same protocols as production data.
  SUPPLIER RELATIONSHIPS
Information security in supplier relationships
 
15.1.1 Information security policy for supplier relationships Refer AWS security compliance and mydigitalstructure.com/terms
15.1.2 Addressing security within supplier agreements Refer AWS security compliance
15.1.3 Information & communication technology supply chain Documented and refer AWS security compliance
  Supplier service delivery management 
15.2.1 Monitoring & review of supplier services AWS is monitored constantly.
15.2.2 Managing changes to supplier services Highly infrequent, if at all.  Months of planning an risk analysis before any change is made.
  INFORMATION SECURITY INCIDENT MANAGEMENT
Management of information security incidents & improvements
 
16.1.1 Responsibilities & procedures Documented
16.1.2 Reporting information security events  Events are reported to all stake-holders as soon as they are known, including the @ibComMYDS twitter account and status.mydigitalstructure.com.
16.1.3 Reporting information security weakness ibCom has a reward for report program.  All highly sensitive information can be secured using the operations@ibcom.biz PGP public key.
16.1.4 Assessment of & decision on information security events Documented
16.1.5 Response to information security incidents All incidents considered to be security incidents are immediately communicated to all effected stakeholders.  Including the use of @ibComMYDS twitter account & status.mydigitalstructure.com.
16.1.6 Learning from information security incidents All learnings from incidents are immediately applied to the platform.
16.1.7 Collection of evidence Documented
  INFORMATION SECURITY ASPECTS OF BUSINESS CONTINUITY MANAGEMENT
Information security continuity
 
17.1.1 Planning information security continuity ibCom has a full disaster plan - including running mirror instances in other geographical locations.
17.1.2 Implementing information security continuity All mirror sites operate within the same production (operational zone) protocols.
17.1.3 Verify, review & evaluate information continuity Verification, review & evaluation occurs constantly.
  Redundancies 
17.2.1 Availability of information processing facilities Mirror sites are implemented in other geographical locations.
  COMPLIANCE
Compliance with legal & contractual requirements
 
18.1.1 Identification of applicable legislation & contractual requirements Documented.  All encryption of personal data is the responsibility of the customer.
18.1.2 Intellectual property rights All software and information intellectual property rights are well known and managed.
18.1.3 Protection of records All records are highly protected.
18.1.4 Privacy & protection of personally identifiable information All private information is highly protected.
18.1.5 Regulation of cryptographic controls Documented
  Information security reviews 
18.2.1 Independent review of information security Third party certiification is underway (as at December 2013)
18.2.2  Compliance with security policies & standards Constantly being reviewed for compliance.
18.2.3  Technical compliance review Constantly being reviewed for compliance.
 
BP-ISO27001-17-Small.png
Protection & Security
Protection & Security Compliance
ISO/IEC 27001
Browse ISO/IEC 27001
Browse ISO/IEC 27002
Browse ISO/IEC 27017
Browse ISO/IEC 27018
Download as a PDF
Amazon Web Services Security Compliance

 

 

  Download as a PDF