CARDS2 Discussions

• Conversation: creating a new application to replace a legacy one should include workflow and policies. Applying a new application/solution to the same rough/outdated workflows and polices will result in a bad product, or no real gains from the previous system aside from being new. A new solution should enable workflow and policy efficiencies.

A major goal (at dhs at least) should be to eliminate as much printing/scanning of paper copies as possible, what's the point of an accounting system if it's second to a mess of printed papers.

• Certain equipment short-titles need to have required software version. Software version needs to be a gated value that's recorded only at the COR level, so that CAMs can select from a list of appropriate values. This will prevent garbage data from being inputted to CARDS. Really all serious details of a Short-title should be gated, bad values to include allowing CAMS to enter incorrect short-titles should be prevented. CAMs regularly fat finger STs when bringing an item back in from a national account. Actually on this note, "CARDS2" could perhaps scrape the short title lookup page. The website that provides search is pretty terrible though, I wrote a script to help with searches, but it would be an authoritative source to get short titles.

• CAMs should be able to perform Relief of Accountability, Reports of Possession, Removal and Addition of Account Users, Corrections, <More things>. However these actions should work as a request, accompanied with justification. The COR Admins would be notified of the requests and could approve the request/deny with justification or escalate to incident.

• We need a deeper insight on the steps that happen leading up to an incident. CARDS2 should have a incident management system, rather than having account fill out a pdf. users would be able to mark items within the system as things that need to be investigated, similar to how kmi operates.

• User enrollment should also be rolled into CARDS2; the current process causes too much disconnect and doesn't provide visibility to all members of the COR. The challenge here will be working with documents, as a wet signature is required, and protecting PII.

• Is it possible to have API Integration with the GEM or Vines? There would be tremendous benefit if CARDS2 could push directly into those platforms, or pull equipment status ie sw version

Build an additional system that acts as a universal GEM or Vines, I've tinkered with lackluster powershell scripts to ease KG upgrades, and I think it would be doable to build a tool that performs like GEM or Vines

• Gated high > low notifications is a must.

• For asymmetric key, is there a way "CARDS2" could create a platform/equipment package, so when key is downloaded it's easier to associate after the fact for things not connected to a GEM/Vines or if a homegrown gem/vines is out of the picture.

• We need to take logging/monitoring/observability into our own hands instead of waiting to be told there's a problem ie: ELK stack, Apache Skywalker etc

• Taking phone calls for help is really a poor way to go about things, we often even get calls from people asking for help when they're not even in front of CARDS. This also provides no way of logging things that are going on so we can't see any trends, nor does it help build a knowledge base that can be shared.

• what if... we had one deployment of "CARDS2" in C2S that integrated with respective authorization services (ldap etc). A multi-tenant service that made it even easier to new CORs or small groups looking for a COMSEC accounting solution. there would be no one off deployments, it would just be a service in the cloud. We'd sell support like we have been, but costs for a big boy aws deployment are there as well, plus we'd need a govie sponsor for us to get c2s resources spun up. plus if done right it would be trivial to quickly deploy on a higher or lower network via AWS/C2S. General access could be gated at respective orgs auth, like a ticket request for access and also determine which tenant they are.

The service would only have to obtain one accreditation, and then would be come available to all of our existing clients. All these companies that still us DIAS, they would also have the appropriate networks at their offices and would be able to reach this service. This would also open the door to making cross domain between C2S's even easier, like if you have accounts that are on one network but their cor is on another etc. Compliance and accreditation would likely be even easier since c2s has vms that are maintained for this. This approach is everything iapp isn't, it wouldn't be just another monolithic comsec tool to slap on your network, with the extra headaches of A&A/maintenance etc.

The following are some notes that came out of a early meeting at dhs

F5

               LTM  - local traffic manager https://www.f5.com/products/big-ip-services/local-traffic-manager
               They don’t provide auth, but they could if we present the need.
               They can provide DNS routing
               Detect Failure of the app for failover, they’d need a means for monitoring.
               

PKI/Janus ICAM

               SAML(https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language), OIDC (I think he said this, it’s openid (https://openid.net/connect/) connect) , SSO - We’ll end up integrating with SAML or OIDC, sso would be nice if we have an ecosystem of comsec workflow apps
               We’ll be able to pull user attributes from them, username, names, org etc. This will provide very granular access to “cards 2”, someone with an hsdn account will be able to hit our page and be authenticated, but only have access to a landing page.
               

Applications and Containers Guy

               Their workflow: they develop in AWS on the lowside, when ready they have it DTO’d up for deployment.
               They have a docker swarm (https://docs.docker.com/engine/swarm/key-concepts/) app, secure enterprise portal
               They have future plans for devops pipelines on HSDN, source control, Jenkins, repos and mirrors, etc
               We may be able to leverage their docker swarm deployment, although I don’t think docker swarm is necessarily a true multi-tenant solution, so our secrets/keys for SQL could potentially be exposed.
               note: I do think docker swarm would offer the best deployment environment, swarm could negate needing F5 as it does do routing(https://docs.docker.com/engine/swarm/ingress/), but I think we’d either use their F5 w/ auth for granular auth, or we’d have our own apache reverse proxies deployed in swarm to do load balancing & granular auth. 

if we produce containers on the lowside as the deliverable we don’t care what the host OS is, as long as it can run docker, docker swarm or another container hypervisor

OWT H>L We would shoot XML with the message to their SFTP or Windows Share, the XML would be checked against our approved schemas and then transferred lowside. They fortunately have plans on accepting JSON as well. Since this process involves them ingesting our XML to check and transfer we would need a something on A-LAN that ingested the XML, parsed and emailed the message. We’ll need to see what level of effort to obtain a small VM.

2/9/2023 Aquarian CARDS DHS Meeting

Dan Big thing: Download red TrKEK from CARDS (Fill to devices) Who do we talk to at NSA to understand if there’s any possibilities to do this properly? For example KMI DOCKS (Spelling) should be able to do this over the network but they use a token.

                               One contingency TrKEK, not all the accounts TrKEKs, and it’s only available for fill to CFD. 
                               ConTrKEK(OpTrKEK) -fill-> CFD

Currently we send new TrKEK wrapped in their current TrKEK. The new TrKEK is a different Short title. Also to note…. All FEMA accounts are TS, so the contingency key for FEMA accounts is TS when red… TrKEK talk spiraling to electronic DRF (currently blank paper out of band)

Dan: Strength in numbers, he has his wish list, but understands roping in DoS FBI etc etc to build a better product

Searching, better searching, CARDS does currently have searching, but I don’t think it’s exposed to CAMs (spotlight available in DoS CARDS)

Java Script and Palisade

               Asked about A&A for Palisade, it’s under iApps ATO.
               Concern about ATO/A&A to bring Palisade in.
               Can Palisade run in a VM? Dan says you can’t load thins on a thin client.. 
                               Serial/COM port access to a thin client. 
               Concerns about machine re-imagining blowing away settings
                               Solved by user profiles or a COMSEC specific machine image
                               Having app available on Software Center
                               It’s honestly hard working with the HSDN folks. They will say things are solved, but they won’t be solved (GPO for serial/com ports)
               HSDN program office contacts: Greg Evans, Bible
               Dan: Palisade is the ‘engine’ and accessed via browser
               Dan is wondering about a Citrix (or similar) based app when he talks about VMs
                               Browser based Citrix like application? How does interaction with Serial/COM ports work?

               There’s animosity and perhaps a misunderstanding about ‘Java’, it’s a dirty word up here.
                               Java-script served via browser = bad
                               Java running on as an app = good 

Oracle > SQL Migration

               ~80K a year they’re paying for oracle right now, expecting to breach 100K with price changes.
               Approach to moving away from CARDS
                               Palisade using enterprise MS SQL, Palisade working from browser.
                               Comparisons to KMI (KMI runs locally, has a local database, despite the conv, you can login without a connection.)
               JC: 1-2 people for 2 years thought the numbers were conservative
               

Additional Capabilities NCIRS machine to machine API for incident reporting? CAM nominations/personnel workflow PII Concerns Are there existing approval tools used on HSDN for automating administrative functions.

Jim Questions:

               NCIRS on high side
               Forms and adding initial pdf report to incident
               Personnel administration, separate crypto access brief 
                               No database
                               Pii bad 
                               Just adding here: is there a high side service for work flow? There should be an source to enable machine to machine queries to validate access.

Features page TACLANE Key tracking -> Filled in device tracking (Although, is there an API where we could have a machine to machine GEM API? Where we could push key to it and receive device information) Described that we’d seek feature parity first before tackling enhancement

KMI Aware

               Still a nice to have dream that might have in the 5 years or later (They’ve been saying it for the past 10 years)
               Dan: would rather see a COR feature in KMI 
               iApp serves as a KMI store front to help get to the last mile (cross domain), serves as a GEM so to speak

Look at the bigger picture and breakout into smaller chunks for better planning/pricing/time

Dan: new mangt at DoS their thoughts and feelings about it all and a new CARDS.

               Daniel fixing and adding features to IApp. iApp will be like the DoS Page Group at DoS. 
               Is DoS sold and stuck on iApp?

CARDS is approved as a CMCS. How do we get a new product approved?

               iApp is not approved
               What is an approved system? Is it just the fact that the systems only store Black Key? Everything else is just classification.