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.

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.
               POC Damon Freeman

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.
               POC Ceaser Benavides, Christopher Strem

Eddy Applications and Containers Guy (I do want his full name)

               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. POC Steven Nevid, Dale Hensley