<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Government Contractor Using Atlassian Data Center Partners with Isos Technology for Custom Development to Support Stringent Security Protocols

Daily
departments optimized

Zero
tolerance security policy

Three
separate Atlassian instances

Project Snapshot

  • A government contractor with high-level security clearance was using the Atlassian solution set, including Jira Software, Jira Service Management, and Confluence. Each application ran in a separate Docker container.
  • The company had strict security protocols that required shutting down the Atlassian systems, wiping them clear of all data, and starting from scratch if sensitive information was inadvertently mentioned. Backups or restores were not sufficient for the security requirements.
  • Isos had previously developed a proprietary process called “Click-to-Clone” that enables companies to clone systems, both on an automated schedule and manually, and store those clones securely on a separate node for a predetermined length of time.
  • Isos undertook custom programming to ensure Click-to-Clone worked in the company’s Docker environment and to clone each solution both with and without data.
  • Now, should data leakage occur, causing the company to have to shut down its systems and wipe all its data, internal adims can use the clone made just before the leakage incident to quickly and easily get their system up and running again.
  • In addition, the company can use Click-to-Clone on an as-needed basis to clone its production environment to development without data to limit the possibility that sensitive information could be exposed in this environment.
isos-federal-logo-1

Our client

A government contractor with high-level security clearance was using several Atlassian Data Center products, including Jira Software, Jira Service Management, and Confluence. For security purposes, the company had each application running in its own Docker container. Due to the sensitive nature of the information and data the company handles, stringent security protocols are in place, and certain sensitive information is prohibited from being processed within the Atlassian stack. Despite the vigilance of the internal team, there is still a risk of human error, as even a minor mention of sensitive information in a comment on a Jira issue, in a JSM ticket, or on a Confluence page is considered a data leakage. 
gov-insitution-oh

Challenge

The company had two primary challenges. First, if there were a security breach, even a small one, the organization would need to shut down the affected Atlassian application, wipe it clear of all data, and start from scratch–a backup or restore was inadequate. The company needed a secure, fast, and efficient solution for getting up and running again with minimal disruption should data leakage happen. Second, the organization had both production and development sites for each of its Atlassian solutions. To support data segregation, enhance security, and minimize risk, a method was needed to replicate the production site to development without compromising data.

Solution

Isos had previously developed a proprietary process called “Click-to-Clone’’ that enables companies to clone systems, both on an automated schedule and manually, and store those clones securely on a separate node. After a predetermined length of time, the clones would be automatically deleted. After discussing it with the client, it was determined that Click-to-Clone would be an effective solution for both challenges. However, before it could be implemented, Isos had to undertake significant custom programming to ensure it would work in the company’s Docker environment.

 

gov-security

Results

Now, the company uses Click-to-Clone to clone each of its Atlassian applications. It is a regularly scheduled job that takes place automatically each night, and the clone is stored securely on a separate node. Should data leakage occur that results in the company shutting down the impacted application and wiping its data, the clone made just before the leakage can be used to quickly and efficiently get the application restored. In addition, the company can use Click-to-Clone on an as-needed basis to clone the production environment to development without data to limit the possibility that sensitive information could be exposed in this environment.

Download Case Study