Deadline Date: Wednesday 6 November 2024
Requirement: Atlassian Confluence Federation and Replication Mechanism Proof Of Concept
Location: Off-Site (The travel expenses for Site Acceptance Test in SHAPE, Mons Belgium shall be included in the bid)
Note:Please refer to your Subcontract Agreement, article 6.4.1.a, which states “Off-Site Discount: 5% (this discount is applicable to all requirements, and applies when the assigned personnel are permitted to work Off-Site, such as at- home)". Please be sure to price this discount in your overall price proposal when submitting bids against off-site RFQs
Period of Performance: As soon as possible but not later than 04 December 2024 until 30 June 2025
Required Security Clearance: NATO RESTRICTED
1. Bidding Instructions:
1.1. Technical Proposal
Bidders shall submit a proposal clearly providing the following information:
a. The proposed approach to address the required scope of work and the required delivery and milestones plan.
b. CVs and Attestations of the assigned resource(s) for the project. It is up to the bidder to propose the size of the team that executes the work and produces the deliverables in the timeline allocated.
c. A compliancy matrix clearly stating how your proposal meets the deliverables/ performance goals outlined in Part 2, Section 2.
d. Any other appropriate technical information to determine whether your proposal meets the deliverables/ performance goals outlined in Part 2, Section 2.
e. Any other similar past performances explaining the relevance of the bidder with the requirements and elaborating on why they are the best candidate for this contract award.
2. Award
The contract shall be awarded under the framework contract CO-115786-AAS+ - Market Place 1.
1. INTRODUCTION
The NCI Agency has been established with a view to meeting the collective requirements of some or all NATO nations in the fields of capability delivery and service provision related to Consultation, Command & Control as well as Communications, Information and Cyber Defence functions, thereby also facilitating the integration of Intelligence, Surveillance, Reconnaissance, Target Acquisition functions and their associated information exchange.
The NATO Cyber Security Centre (NCSC) is a team of over 200 members working to monitor and protect NATO networks. In the NCSC’s role to deliver robust security services to the NATO Enterprise and NATO Allied Operations and Missions (AOM), the centre executes a portfolio of programmes and projects around 219 MEUR euros per year, in order to uplift and enhance critical cyber security services. The Portfolio ranges from Programme of Work (POW) activities funded via the NATO Military Budget (MB) to Critical / Urgent Requirements (CURs/URs) and NATO Security Investment Programme (NSIP) projects funded via the Investment Budget (IB). In some edge cases, projects are also funded via the Civilian Budget (CB). Projects can span multiple years and are governed by various frameworks, including the Common Funded Capability Development Governance Framework (CFCDGM).
In order to execute this work, the NCI Agency is seeking for expertise to develop a replication mechanism between 2 Atlassian confluence instances responding to all the requirements (technical and functional) captured in the chapter 3 “Requirements” below and the associated Annex A. These 2 instances cannot directly communicate with each other.
2. DELIVERABLES
D1. The contractor shall demonstrate the technical concept to achieve the requirements laid out in the Statement of Work
D1 Outcome: An approved technical concept for implementing the solution
D2. The contractor shall demonstrate in a test environment the technical implementation of the replication mechanism for new content, being a space or a page.
D2 Outcome: The demonstration is confirming that the solution is able to transfer a confluence page or a confluence space from one environment to the other environment.
D3. The contractor shall demonstrate in a test environment the technical implementation of the replication mechanism for handling update and deletion of existing content.
D3 Outcome: The demonstration is confirming that the solution is able to replicate update or deletion of confluence page or a confluence space from one environment to the other environment.
D4. The contractor shall demonstrate the solution is able to handle exceptions and errors, and that the logging mechanism for troubleshooting is meeting the requirements. The solution will include safeguards to prevent the failure of the content to be replicated and what has been replicated
D4 Outcome: The demonstration is confirming that the solution is able to handle exception and errors, and provide the level of logging appropriate to a Confluence administrator to handle the error and rectify the error. The safeguarding mechanism will have to be demonstrated.
D5. The developed solution is passing the Site Acceptance Test and delivered to NCSC.
D5 Outcome: A fully working (as per chapter “3. requirements” below and associated “Annex A - detailed technical requirements for implementation”) replication mechanism of Atlassian Confluence, implemented on a test environment and delivered to NCSC on a collection of virtual machines in VMWare format, with full access to all content and developed
D6. The contractor shall fully document the solution and the development code associated. The ownership and copyright of the code shall become the property of the NATO Communications and Information Agency.
D6 Outcome: A documentation, in Atlassian Confluence format covering: A high level design of the solution; A detailed design of each component of the solution; An administration and troubleshooting documentation; Extensive source code documentation allowing for maintenance and improvements
3. REQUIREMENTS
3.1 DATA REPLICATION REQUIREMENTS:
1. The solution should take a form of plugins for Atlassian Confluence.
2. The plugins shall work in DataCenter edition of Confluence environment in the versions currently installed on NCSC networks on the day of awarding the contract. (8.5.12 LTS)
3. The underlying operating system is Red Hat Enterprise Linux 9 (RHEL 9)
4. The 2 Confluence instances cannot communicate directly. Each instance can access a dedicated Samba network share to write or read files.
5. The content shall be transferred as encrypted files using public private (PKI) keys (at no time the content outside Confluence can be unencrypted)
6. Solution shall work with NCSC delivered pairs of certificates and private keys.
7. Solution shall allow for changing the certificates and associated private keys as often as needed from the user interface or command line interface on the servers without any need to recompile or change the code
8. Encryption and decryption as well as export and import methods should be exposed as REST Endpoints methods for allowing some ad-hoc script-base troubleshooting and fixing
9. Solution should automatically check validity of certificates using base on the certificate CDP (CRL Distribution Point) CRL or OCSP.
10. The replication will occur only one way
a. Shall allow defining the Replication Partners with associated certificates
b. Shall allow to configure the plugin to be the exporting or importing node.
c. Shall have all its configuration parameters available and modifiable on the web interface of the plugin within Confluence.
d. Shall allow for independent definition of the landing zone (network share) for export purpose and pick up zone (network share) for import purpose. The network share will be accessed using protocol Microsoft SMB version 3.
e. Shall replicate all of the data in destination partner exactly as it is presented in the source partner, in the correct chronological order, that includes all data, comments, workflows’ states, timestamps, attachments, users, spaces, update history, graphics, embedded elements (including objects from other plugins, e.g. Gliffy for Confluence), links, etc.
i. In case the user is missing the new user of the same name shall be created. It shall be deactivated. User creation shall be logged.
ii. User group ownership and associated Role-Based Access Control (RBAC) shall be respected.
iii. The newly created user needs to belong to equivalent groups of those to which the original user belonged. If any of the group do not exist it has to be created with the same name and it needs to belong to equivalent groups to those which source group does (Nested Groups).
iv. Tracking of any problem in the replication mechanism will be tracked in an automatically generated Atlassian JIRA issue.
v. Every replicated object/content will indicate its originator partner.
f. Shall allow for defining which elements to be replicated from the source to the destination partner.
g. Shall indicate for each page the originating network, and make the page read-only.
h. Any change to the above elements shall trigger delta replication
i. Links and custom fields IDs shall be translated in consistent way to prevent breaking the links in the content
j. On the destination partner there shall be periodically scheduled job to check if a synchronization file appears in the pick-up zone. Frequency of the checks shall be customizable. If there are multiple replication files present the job should trigger the import in order of files creation timestamps.
11. All functions shall be configurable from User Graphics Interface in Confluence.
12. Solution shall use native JIRA & Confluence mechanisms as much as possible
13. Solution shall have extensive logging capability with defined at least levels of logging to allow audits and troubleshooting. Logs shall be stored in dedicated log files. Logs shall be in structured format and human-readable (JSON, XML,…)
14. Solution shall provide exact replication of the information from the source system.
15. Further detailed technical recommendations for implementation are part of Annex A.
3.2 SUPPORT TESTING AND VALIDATION REQUIREMENTS:
Solution Acceptance Test (SAT) is to be conducted on NCSC test environment prior the implementation on the operational environment
Above activities shall be supported on NCSC premise by the contractor.
3.3 DOCUMENTATION REQUIREMENTS:
Language: the product shall be written in English, meeting the NATO STANAG 6001 Level 3 “Professional Proficiency”.
Intended Audience: the product shall be intended for Cyber Security Professionals.
Accuracy: the product shall accurately reflect what was discussed, decided, and action items assigned during the meeting.
Clarity and Conciseness: Information shall be presented clearly and concisely, avoiding unnecessary jargon or complex language.
Formatting: Consistent formatting shall be used throughout the document, including font style, size, headings, and spacing further directed by the NCSC.
4. REPORTING
R1. On a biweekly basis, a videoconference shall be held to review the progress of the development of the solution and the state of the documentation of the solution
5. SKILLS
[See Requirements]
6. WORK EXECUTION
The development can be executed on any development environment.
Progress review meetings shall happen using videoconference at least once every 2 weeks.
Final testing (Site Acceptance Test) of the proof of concept shall happen on NATO premises (SHAPE, Belgium).
7. DELIVERABLES MILESTONES AND PAYMENT SCHEDULE
Payment will be done as per the milestones below and in accordance with the table below:
D1: 10 JAN 2025
Type and conditions of payment: After approval of D1 by NCIA SDM and signed Delivery Acceptance Sheet
D2: 15 FEB 2025
Type and conditions of payment: After approval of D2 by NCIA SDM and signed Delivery Acceptance Sheet
D3 15 MAR 2025
Type and conditions of payment: After approval of D3 by NCIA SDM and signed Delivery Acceptance Sheet
D4 15 APR 2025
Type and conditions of payment: After approval of D4 by NCIA SDM and signed Delivery Acceptance Sheet
D5 31 MAY 2025
Type and conditions of payment: After approval of D5 by NCIA SDM and signed Delivery Acceptance Sheet
D6 30 JUN 2025
Type and conditions of payment: After approval of D6 by NCIA SDM and signed Delivery Acceptance Sheet
The payment shall be dependent upon successful acceptance of the Delivery Acceptance Sheet (DAS) – (Annex B) including the EBA Receipt number.
Invoices shall be accompanied with a Delivery Acceptance Sheet (Annex B) signed by the Contractor and the project authority.
8. TRAVEL
All travel costs are included in the quoted price. No additional cost for travel (including accommodation, per diem, travel expenses, etc.,) will be claimed separately. All travel arrangements are the responsibility of the contractor.
9. PERIOD OF PERFORMANCE
The period of performance is as soon as possible but not later than 04 December 2024 and will end no later than 30 June 2025
10. SECURITY AND NON-DISCLOSURE AGREEMENT
Any contracted individuals of the Service Provider must be in possession of a security clearance by their National Authority of NATO RESTRICTED. The signature of a Non-Disclosure Agreement between any Service Provider’s individuals contributing to this task and NCIA will be required prior to execution.
Annex A – Detailed Technical Requirements for Implementation
1. Solution should provide a mutex mechanism per page that allows editing only on either Sender or Receiver instance.
a. Default should be that editing is allowed on the Sender side.
b. The switch for the mutex should be available for all users that have an Edit permission on specific page on the Sender side (not through the CTGUI).
c. The status of mutex shall be visible on bot Receiver and Sender sides
d. If mutex is set to allow editing on the sender side, editing in not allowed on the Receiver side and replication from the Sender to Receiver shall occur unless configured otherwise in CTGUI
e. When mutex is set to allow editing on the Receiver side it prevents any further editing on Receiver side unless mutex is switched back by admin (this actin shall be available only for the members of specific user group e.g. mutex-control-users). It also stops synchronization for this page.
f. Mutex mechanism shall not alter permissions in spaces or particular pages.
2. The Sender
a. CTGUI for Admins
b. shall be triggered by Confluence system Events (Event Listener)
c. Non-content events should be disregarded with the exception of Access Control Lists (ACL) changes
d. It shall be configurable per Space basis whether synchronization should occur or not with default action for the remaining spaces (default: not). All configurable from CTGUI
e. Information that shall be replicated fully (no change) consist of
• content
• its contributing users (collaborative editing in on for whole solution)
1. due to fact that users might have different names on both instances an exceptional translation table shall be established on the Receiver side
• and related timestamps
• or/and permissions changes
• mutex status
• ACL change
• AES 256 key (see below)
• Administrators gpg keys
f. Each event shall create an update file that will be sent to configurable from CTGUI Samba share
i. This update file shall be encrypted with AES 256 preshared key
1. This preshared key should be established every night at specific hour (configurable from CTGUI) and should consist on 40 random characters from the following set
• Small letters
• Capital letters
• ~!@#$%^_+=-`|\:”’;<>,.?/
2. The AES 256 key shall not be stored unencrypted in the DB, filesystem, etc.
• Unencrypted version only in memory
3. The key should be generated and encrypted with public key of the specific public private pair (gpg) of keys (upload-able through CTGUI) and replicated (via specific update file) to the Receiver at the specific time (point 1) where the Receiver will use the private key to decrypt it. Note that the Receiver shall store they AES 256 key in dedicated folder on the Confluence server (both Receiver and Sender) which should be encrypted with GPG with multiple recipients (plural, see reference link below). These gpg key for specific users (Administrators gpg keys) should be upload-able from CTGUI on the Sender side. The point of this is to allow advance troubleshooting for administrators.
4. Reference gpg mechanism’s link: https://www.gnupg.org/gph/en/manual/x110.html
ii. The update file should have a filename that contain a space, date-time timestamp and counter for ensuring data integrity on the Receiver side, e.g. MySpace_2024-01-01_00:00:000_0123
iii. Extension .sync
iv. There should be a mechanism in CTGUI that would allow manual trigger for regeneration and synchronization of the AES 256 key
v. There should be a mechanism in CTGUI that would allow to create an empty update file with specific metadata to allow fix missing update file.
g. There should be a mechanism, accessible through CTGUI which will allow for resending update(s) file manually to allow for possible troubleshooting using previous or current or manually provided AES 256 key and either keeping its/theirs original counters or shift them by set number.
h. There should be an option CTGUI to set counter (per Space) to arbitrary number.
i. All the update files shall be cached in dedicated Confluence server folder (CTGUI configurable) for certain amount of time (CTGUI configurable, default 2 weeks)
j. There should be an CTGUI page that would allow viewing and troubleshooting the update files cache.
3. The Receiver
a. CTGUI for Admins
b. Should be a scheduled job that can have different time triggers (crontab like) per space, configurable from CTGUI
c. It should look for update files in a CTGUI configured samba share (note: not the same as on the Sender side)
d. Base on character of the specific update file it should either establish new decryption or start synchronization
e. The job should establish a queue of updates per specific space and should control if updates are coming in order (see description of update file filename) and the required users exists on the instance
i. If there is a missing update file (next file already received) for configurable (CTGUI) amount of time (default 2 minutes) synchronization should pause on the Receiver side (new files shall still be queued). Email notification should be sent to predefined users (CTGUI) and warning banner should be displayed for them as well in the Confluence interface.
ii. There should be an option CTGUI that would allow to arbitrary set expected update file counter for specific Space.
iii. If there is a missing user on the Receiver instance synchronization should pause on the Receiver side (new files shall still be queued). Email notification should be sent to predefined users (CTGUI) and warning banner should be displayed for them as well in the Confluence interface
1. Due to fact that users might have different names on both instances an exceptional translation table shall be established on the Receiver side.
• Configurable on the CTGUI as one to one relation Sender username -> Receiver username
• This table shall be exportable and importable in both CSV and JSON formats
f. After the issue is resolved the synchronization should restart where it stopped processing queue updates.
g. All update files should be cached in dedicated folder (CTGUI configurable)
h. There should be CTGUI page that allow for troubleshooting cached update files and queues
i. It should allow for seeing the files, counter queues and alter their metadata in support of troubleshooting.
1. There should be an option to allow manual use of different (ad hoc provided) AES 256 key for allowing decrypting files that stuck due to some glitch during key change synchronization to be processed
i. Decryption mechanism and key synchronization was described in the Sender description.
j. Mutex as described earlier shall not change permissions on pages or spaces
k. ACL changes should perform the same checks as regular content updates with the same mechanism for control and troubleshooting.
l. Decryption synchronization mechanism and decryption itself errors should be reported the same way as content and ACL errors
m. In case that the required space does not exist on the Receiver side it shall be created exactly copying all the properties and attributes, timestamps, ACLs, etc. of the original one on the Sender side. User translation shall be applied in the process.
5. SKILLS
It is up to the bidding company to propose and size the team that will be working to fulfilling these deliverables.
Nevertheless, the person or team of persons working on this statement of work shall collectively (not for each individual) have the following skills:
- Intimate knowledge of the inner working of Atlassian Confluence at code and database level
- Mastery knowledge of ScriptRunner
- Mastery knowledge of using REST API and listeners
- Excellent knowledge of Linux operating systems
- Excellent knowledge of JAVA
- Excellent knowledge of Python
10. SECURITY AND NON-DISCLOSURE AGREEMENT
- Any contracted individuals of the Service Provider must be in possession of a security clearance by their National Authority of NATO RESTRICTED.
See more jobs at EMW, Inc.
Apply for this job
