MXS Cloud SDK
Multi-X Security
Software Development Kit
Multi-Level
Multi-Category
Multi-Nation
Maxus Cloud SDK, the Multi-X Security Software Development Kit Hello, and welcome to the Maxus cloud software development kit briefing. This briefing will cover the basics of the Maxus Cloud SDK. If you’d like to hear more information about what you’ve seen in this brief, please contact Major Kyle Stewart at kyle dot stewart dot 5 @ US dot AF dot mil. MXS, pronounced “maxus”, stands for Multi-X security. The maxus project objectives are to provide secure multi-level, multi-category, and multi-nation environments. Categories are the maxus term for what some might call a compartment, caveat, or program.
1
Historical Context
2
The major problems of the USAF stem from the fact that there is a growing requirement to provide shared use of computer systems containing information of different classification levels and need-to-know requirements in a user population not uniformly cleared or access-approved. …
Users are permitted and encouraged to directly program the system for their applications. It is in this latter kind of use of computers that the weakness of the technical foundation of current systems is most acutely felt.
Computer Security Technology Planning Study (Volume II)
October 1972
2
Challenges & Solutions
MXS Reference Architecture
MXS Security Model
Challenges
Current commercial cloud infrastructure does not provide a multi-level / multi-category environment out-of-the-box; it must be provided by workload owner
It is difficult for vendors and mission owners to create multi-level / multi-category aware software
Unclear approach to data labeling impedes interoperability and complicates development of software solutions that function across the enterprise
Solution
Execute project that develops a standard security model, data model, reference architecture, and Software Development Kit (SDK)
Conduct prototyping in an unclassified cloud environment to demonstrate feasibility of using the MXS SDK to develop multi-level / multi-category software solutions
When successful, utilize the MXS SDK to address IT requirements related to enterprise software development
3
3
Enterprise View
4
4
System View
5
5
What is MXS Cloud SDK?
Increasing Technical Opinion
Documentation
Security Model
Data Model
Reference Architecture
Reference Implementation
Cost Model
Human-centric terms and definitions with concepts modeled in a well-defined visual language
Machine readable data formats for access control information and metadata aligned to security model
Organization of COTS/GOTS components into solution which supports security and data models
Executable form of reference architecture that runs inside government owned cloud environment
Provide cost predictions for reference implementation including licenses, compute, store, and network
Acquisition and developer centric documentation that covers requirements, use cases, testing, etc.
6
6
Business Processes
Multiple organizations participate and contribute via DI2E DevTools based on Atlassian tools (Confluence, JIRA, BitBucket) + Jenkins Milestones are 4-week planning periods (i.e., sprints) All work is drafted, approved, and tracked via JIRA tickets Clear “definition of done” with deliverable required for ticket approval Documentation (including this briefing) is all tracked and built from version control
7
7
Generic Security Model
8
8
Claims 0.1
{ “urn:us:gov:ic:uias:digitalIdentifier”: “CN=Lastname Firstname Middle personId, OU=PE, OU=DoD, OU=DoD, O=U.S. Government, C=US”, “sub”: “7fbdecb9-7b1c-4663-bf7e-3e70b57f681e”, “urn:us:gov:ic:uias:aICP”: false, “urn:us:gov:ic:uias:dutyOrganization”: “ABMC”, “urn:us:gov:ic:uias:dutyOrganizationUnit”: “CIO:APPS:EASPO”, “urn:us:gov:ic:uias:entityType”: “CTR”, “email_verified”: false, “iss”: “http://localhost:8080/auth/realms/hello-world”, “preferred_username”: “Firstname.Lastname”, “urn:us:gov:ic:uias:clearance”: [“TS”, “S”, “C”, “U”], “aud”: “siteapp”, “urn:us:gov:ic:uias:countryOfAffiliation”: [“USA”], “urn:us:gov:ic:uias:adminOrganization”: “ABMC”, “urn:us:gov:ic:uias:entitySecurityMark”: “U”, “urn:us:gov:ic:uias:auditRoutingOrganization”: “Routing Org”, “urn:us:gov:ic:uias:authorityCategory”: “ICD503”, “urn:us:gov:ic:uias:group”: [“my-group”, “my-group-two”, “your-group”], “urn:us:gov:ic:uias:region”: [“EMEA”], “urn:us:gov:ic:uias:role”: [“DoD-MXS-Admin”, “NATO-Liason”], “urn:us:gov:ic:uias:topic”: [“HLTH”], “urn:us:gov:ic:uias:certificateAuthority”: “DoDPKI”, “urn:us:gov:ic:uias:originatingNetwork”: “NET1″, “email”: “Firstname.Lastname@world.com”, “urn:us:gov:dod:contractorOrg”: “ACME Inc.”, “urn:us:gov:dod:contractorOrgId”: “91749”, “urn:us:gov:dod:authorizationSet”: { “XMS”: { “M”: { “CAT1″: [“ABC:1234″] }, “H”: { “CAT1″: [“APPLES”], “CAT2″: [“DEF:9876″], “CAT3″: [“BANANAS”], } } } }
Claims are represented by Open ID Connect JSON Web Token (JWT)
Design is split into “heavy” JWT (backend authorization) and “light” JWT (held by client)
Leverages semantics from IC UIAS standard as well as from OSD SAP CIO
Format depicted here includes explicit, long namespaces to make it clear the origin of the semantic
All labels and markings are notional and for illustrative purposes only.
9
Clearance Owner:->“XMS”: { Level:—>“M”: { Category Type:——->“CAT1″: Categories:—————>[“ABC:1234″]
9
Information Security Marking
Multi-Level Markings (MLM) occur when there is a mixture of classification levels and categories portion marked within a document
Standards like ISM potentially can misrepresent the aggregate precisely, resulting in over classification at the root level
MXS is working with OSD SAP CIO and Common Metadata Standards Tiger Team (CMSTT) on possible implementation strategies and policies
10
All labels and markings are notional and for illustrative purposes only.
10
Label 0.1
Derived from ISM semantics including JSON-LD distributed controlled value enumeration files
Added additional structure in key areas of concern to address challenges with mixed classification level, categories, coalition data, and developer ergonomics
Works together with MXS Claims JWT
Designed to accept, produce compliant ISM labeled data
Stepping-stone to next-generation labeled infrastructure based on OPA/REGO
Moving the label to application-level protocols (like HTTP) that leverage JSON makes the shared data model more easily exchanged and validated
Better aligned with modern development techniques and knowledge base in industry
{ “classification”: { “XMS”: “H” }, “categories”: { “XMS”: { “M”: { “CAT1″: [“ABC:1234″] }, “H”: { “CAT1″: [“APPLES”], “CAT2″: [“DEF:9876″], “CAT3″: [“BANANAS”], } } }, “disseminationControls”: [“REL”, “DISPLAYONLY”], “ownerProducer”: [“XMS”], “geoPolitical”: { “FGIsourceOpen”: [“AUS”, “CAN”, “GBR”], “FGIsourceProtected”: [“FGI”], “releasableTo”: [“USA”, “AUS”, “CAN”, “GBR”], “displayOnlyTo”: [“ABW”], “joint”: true },
“classDeclass”: { “derivativelyClassifiedBy”: “MXS Developer mxs@dod.gov”, “derivedFrom”: “Pursuant to SCG ABC version 1.2 dtd 01/01/2020”, “declassDate”: “2070-02-18”, “declassEvent”: null, “declassException”: [“AEA”], “classifiedBy”: null, “classificationReason”: null }, “metadata”: { “DESVersion”: “201903.201909”, “ISMCATCESVersion”: “201909”, “resourceElement”: null, “compliesWith”: “USGov”, “createDate”: “2021-02-19”, “exemptFrom”: “IC_710_MANDATORY_FDR”, “noAggregation”: “false”, “externalNotice”: null, “noticeType”: “DoD-Dist-X”, “noticeDate”: “2021-02-18”, “noticeReason”: “Contains CUI DCRIT”, “unregisteredNoticeType”: null, “pocType”: “ICD-710”, “hasApproximateMarkings”: null, “compilationReason”: “Language”, “excludeFromRollup”: null } }
11
All labels and markings are notional and for illustrative purposes only.
11
Access Control
MXS implements an attribute-based access control (ABAC) model that in turn needs to support mandatory access control (MAC), discretionary access control (DAC), and role-based access control (RBAC) Data model focuses on modern production environments like the service meshes in a Kubernetes environment, deploying “sidecars” via COTS tools like Grey Matter Leverages open tools like Open Policy Agent, and the REGO policy language to express and enforce access control policies Combines the claims and labeling standardization in JSON to create a zero-trust architecture with rigid enforcement throughout the mesh
package mxs default allow = false allow { # has_necessary_attributes sufficient_clearance all_categories } # Ensure that the user has sufficient clearance to view the marking on # the document. sufficient_clearance { # UIAS data has an array of clearances, not the highest clearance doc_classification_num := input.label._classification._classId clearance_number[user_clearances[_]] >= doc_classification_num } …
12
12
Towards 1.0 – MXS ABAC Data Model
Top-down design after gathering taxonomy of existing data semantics from IC and SAP communities
Core specification that deals with the attributes required for access control to support MAC, DAC, and RBAC
Priorities / Trade-offs
Keep data going over the WAN small
Keep data structures as normalized and regular as possible
Follow principle of least surprise
Interoperability with legacy formats
Leverages JSON based JavaScript Object Signing and Encryption (JOSE), JSON Web Tokens (JWT), and SPIFFE for security and certificate management
Future expansion to binary formats like Concise Binary Object Representation (CBOR), or other formats like XML
13
13
Three Tier Architecture
14
14
Reference Architecture
Government owned architecture with focus on use of commercial products and standards
Example open / commercial products:
Example open / commercial standards:
Initial focus is on single-level, multi-category; aligns with cloud architecture
Hooks to facilitate cloud hosted or on-premise cross domain solution
Compatible with MLS data stores and services
Managed, labeled data management and application hosting environment designed to integrate well with K8s DevSecOps pipelines like Platform One
JSON
Schema
System for Cross-domain
Identity Management
15
15
Reference Implementation
Automation Stack
(*) Will support full DevSecOps lifecycle of hosted applications (via GitOps) and service mesh
Used to automate deployment of packages on K8s
Used for orchestration of executable capability
Used to configure the baseline and deploy K8s
Used to create, manage, and destroy baseline infrastructure
Prototype / Experimentation
Hosted in Cloud One Development (C1D) on top of Amazon Web Services (AWS) Used for COTS evaluation, prototype, experimentation, and scalability testing Leverages full C1D guard-railed environment to support potential future expansion to C1 production
Development
U-FEN is primary development environment Minimizes delta to other *-FEN targets Allows connectivity to unclassified identity store to enable ICAM solution Already aligned with Platform One as DevSecOps environment
16
16
Next Steps
Integration with Platform One Integration with Grey Matter Automated Security Analysis
MITRE Caldera for automated pen testing framework
MITRE SAF (Heimdall) for automated compliance monitoring
Deployment to U-FEN Government Functional Testing Groundwork for Operational Pilots
MITRE Security Automation Framework (https://saf.mitre.org
MITRE Caldera (https://github.com/mitre/caldera)
MITRE Heimdall (https://github.com/mitre/Heimdall)
17
17
MXS Roadmap
MXS Cloud SDK FY21 Deliverables
Security Model / Data Model
Reference Architecture
Unclassified Prototype Cloud Implementation
Legacy Integration Guidance
Cost Model
Fences Integration
FY20
FY21
FY22
FY23+
Prototype • GTRI as Prime ⁃ 2371B OTA via AFRL ⁃ 9-month POP • Cloud One Dev / U-Fences + Platform One • Early involvement from AO and test communities • Demo Days June / Oct 2021
Transition & Mature • MXS Data Labeling Standard 1.0 (NIEM / CMSTT) • Upstream to Platform One (Iron Bank / Big Bang) • Enterprise ICAM Pilot • Operational Pilots
Enterprise Software Factory • Sustained Capability Development ⁃ Leverage DevSecOps ⁃ Built on Platform One ⁃ MXS SDK (Cloud / Edge) • Production Cloud Environments ⁃ Cloud One (IL5, IL6) ⁃ *-FEN ⁃ C2S
Impact • Empowers customers with DevSecOps as-a-Service • Lowers bar for third party developers to create multi-level, multi-category, multi-nation aware applications in the cloud or on premise • Government owned architectures supported with COTS products
18
18
MXS SDK Future Architecture
Baked-in resiliency to denied, disrupted, intermittent, and limited environments Takes advantage of strengths of both cloud and on-premise data centers Builds upon the use of commercial and government standards
WE HAVE DONE THIS QUESTION BEFORE, WE CAN ALSO DO IT FOR YOU
GET SOLUTION FOR THIS ASSIGNMENT, Get Impressive Scores in Your Class
Multi-X Security Software Development Kit Hello
