The Context for Intelligent Automation Security

Data is one of the most important assets owned by an organisation. This could be in the form of customer data, financial data, intellectual property, or sensitive personal information.

Business data is often spread across different systems, residing in applications, that may be on-premise or in the cloud. Cloud applications run by service providers can be a mix of mono or multi-tenanted systems. It is imperative to protect this information from unauthorised access and changes as well as ensure it is available when needed. Security breaches can cause data theft, unauthorised data tampering or render systems unavailable, which can be very costly to organisations and result in loss of customer trust, punitive actions from law enforcement, and financial loss.

According to a study conducted by IBM, the average cost of a data breach is around 3.86 million US dollars and it takes on an average 280 days to identify and contain a breach.

Intelligent process automation systems are core to an organisation’s processes and how it interacts with customers, suppliers, internally and with external partners, so it is imperative to ensure these are configured with security as a fundamental principle. Information Security principles and controls are there to protect organisational data against unauthorised use and disclosure, whilst at the same time supporting the organisation’s core goals and strategic direction.

Security measures should never be an afterthought. Implementing security requires consideration at every phase of the solution delivery right through to post go-live phases. It is much cheaper to address security issues in design and development phases than incurring a security issue in production. Poorly implemented security controls bolted on top of an application can result in security being seen as a process inhibitor that impacts operational processes and user experience, but in reality, it’s the design of the security controls that creates the negative impression.

Timing is also important in ensuring that security controls are not an afterthought. Leaving it too late in a project and you risk impacting project timelines and suffering significant delays with fixes being expensive or impacting functionality.

In thinking about security controls and how they need to fit an organisation’s processes, take the example of a typical Digital Mailroom Automation solution, where it is necessary to ensure the system is aware of how many physical and digital (post and email) documents have been received, how long these are stored for, over what duration and who has access to these documents. Now consider the security implications if all documents must be stored as encrypted files, deleted within a set period if received in error or after processing, or partial information can only be seen by certain individuals or teams within the organisation.

In this blog we talk about how to apply security principles at each implementation phase of an automation project. Security should be integrated into the entire solution lifecycle, so it supports every aspect of the solution including design, implementation, and post go-live.

6 Key Areas to Focus on for Securing your Intelligent Automation Systems

1. Team Setup

Project managers, analysts, developers who are all experts in their own field are often intimidated by information security due to lack of exposure and training. This can lead to missing out important considerations during planning and implementation, resulting in security issues downstream in the project. On the other hand, security architects are experts in security, but often possess limited business knowledge to understand the application ecosystem. Due to the differences in objectives and skill sets, there can be friction or a lack of cohesion between project teams and security personnel that can have a detrimental impact on the project.

The project team should have appropriate security representation, support, or training to ensure information security is core to initial system design. This allows others in the team to apply security principles to their domain of expertise and also appreciate and understand what security consultants want.

2. Requirement Gathering & Design 

Security requirements should be defined as part of both functional and non-functional requirements including any compliance needs. Every functional requirement should be reviewed from a security perspective to ensure the security principles are always met. The technical design and architecture should also address security requirements and follow security design best practices

Ask these questions at each stage of the process:

• What data is stored in the system?

All data should be classified appropriately to ensure the right access controls are defined and only privileged users are allowed access. Thinking about our previous example of a digital mailroom automation solution, it will have data about all correspondence received, emails, sender details, attachments, and customer data. Some of this data can contain sensitive personal information.

• Who can access the system and what can they see?

Only authorised users should have access to the system which should allow defining access rights, privileges as well as control access to data assets and operations they can carry out. Data assets should be classified and segregated, and appropriate controls should be in place to ensure sensitive data is only available to privileged users.

• What can they do? 

Map out what users can do with the data they have access to. For example, data read, update, and delete operations should be controlled by privileges.

• Can the data be corrupted? 

Business rules and validation rules should be in place to perform data validation and ensure data integrity is always maintained. These checks should be in place at both API (Application Programming Interface), user interface and any data exchange with external systems to maintain consistency.

• Can we find out what happened? 

Proper audit log should be generated for all system activities whether it is user driven or via API. These logs are useful for audit and compliance purposes.

• What are the risks? 

Appropriate risk analysis should be carried out not just from an operational perspective but also from an Information Security perspective. A risk matrix should be maintained including a mitigation plan, countermeasures, and residual risk.

Consideration should be given as to how security will be impacted with the ever-changing landscape, both internally within the organisation as well as more widely externally. .

3. Implementation/configuration/development

During this phase, technical analysts and developers carry out system configuration and development as required to build the solution.

• Application owner guidelines should be followed in the case of configuring off-the shelf applications. Incorrectly configured software is one of the major reasons for security vulnerabilities in systems. For example, not setting password policies correctly or defining incorrect user roles and privileges.
• Use of any 3rd party products or open-source libraries should be properly vetted. Both configuration and code should be peer reviewed, unit tests should focus on security and it is necessary to ensure sensitive data is not written in log files or event logs. The principle of ‘least privilege’ should be followed when configuring security controls and passwords should be stored encrypted, preferably in a secure password vault rather than as plain text files.

OWASP has some good resources for following secure practices for development and software testing.

4. Testing

During this phase, application systems go through a test cycle to ensure the original requirements are met and the system is functioning correctly. Testing should focus on application security by focusing on Confidentiality, Integrity and Availability of the information stored in the system.

• Test cases should be created with different adversaries (personas) perspectives. For example, internal users, disgruntled employees, erroneous human behaviour, external users, external application etc. These same tests cases should be run with different user accounts and privileges, thereby ensuring a user is only allowed to action and access data as governed by their role.
• The DevOps approach calls for continuous testing at all stages of the project. Testing earlier in the process ensures issues and vulnerabilities are found sooner in the project cycle and the relative cost of fixing these vulnerabilities is lower compared to in later stages.
• Appropriate consideration should be given as to what data is used for testing. Ideally, simulated data sets should be used as it is not a good practice to use live data in non-production environments. If live data is used, then procedures should be in place to secure this data during testing and securely wiped after testing is complete.
• Application penetration testing should be carried out early in the project cycle to ensure vulnerabilities are identified up front and do not come as a surprise near the end. As well as the application itself, user interfaces and all API end points should also be penetration tested, using a CREST approved vendor.
• Performance and load testing should be carried out with full security and encryption controls in place. Several security controls like encryption (at rest and in transit) carry an overhead and can slow down application performance so these should be accounted for in hardware sizing, response times and Service level agreements (SLAs).

5. Deployment 

In order to ensure the infrastructure and network security controls are properly implemented, the solution provider should work with the customer’s network security team to ensure the deployed application fits within the existing IT landscape without adversely impacting any security requirements.

• Unused system end points and services should be closed, and default application settings should be reviewed to ensure they do not pose a security risk. At times, ‘techies’ tend to overlook security in development platforms and often these loopholes can be inadvertently inherited by production platforms. A common example is where on a new deployment, the development platform is converted to a live one to save time or due to software licence limitations.
• It is imperative to maintain a proper demarcation between production and non-production environments. Often the deployment architecture of a production environment may differ from test and development environments, for example, server roles and components sharing the same server can be different. The deployment architecture should be reviewed to ensure these differences do not create any security loopholes.
• Network penetration testing and IT health checks should be carried out to ensure no vulnerabilities exist in the underlying infrastructure. Both application and network penetration testing should be conducted prior to go-live to ensure deployment has been carried out correctly.

6. Post go-live

Software solutions sit in a dynamic environment where the users, data and other systems are continuously evolving. Security considerations should not stop once the solution is delivered in production, but these should be continuously reviewed and updated as appropriate.

• System technicians and support staff need access to live systems for providing support and undertaking maintenance activities and there should be adequate process controls to ensure all support staff use named accounts to access the systems with access being revoked if their role changes.
• Changes to one part of a solution can have adverse impact on other areas. This calls for robust change management controls to be in place. A change impact matrix should be maintained and carefully analysed on which changes should require another round of penetration testing.
• For debugging/fault analysis, any data provided to 3rd parties should not have sensitive data unless appropriate data protection agreements are in place with provision for securely purging the shared information.
• All data and configuration should be backed up periodically. Data backups should be encrypted and stored securely. Access to data backups should be limited to authorised staff only. A Business continuity and disaster recovery plan should be in place to mitigate risk.

At Telic Digital, our consultants have extensive experience implementing Intelligent Automation with key security principles in mind. Should you find your organisation needing some assistance we can be contacted here.