At the beginning of the year
At the beginning of the year I figured out that by dropping a few features of the API the entire design of DeepSentry could be replaced with a multi-tenant IO model. An IO model that shifts user focus away from training the machine learning and configuring the strike operations to a model better suitable the current security industry in the United States that is results-driven, the generation of reports for new activity. With the new IO model DeepSentry can be plugged into any tool that can perform HTTP requests since uploading new machine data drives the downloading of reports.
I finally came to terms with the state of security orchestration, there being plently of freely available tools for network monitoring, configuration management, continuous integration, and continuous delivery. There's no reason why DeepSentry should replace the amazing work of other security-related projects in the industry.
Lots of bugs were closed out
The features of the API which were removed belong to Customized Targeting and Strike Operations. And with those features lots of bugs were closed out and the base is now 10,000 lines shorter!
Training the machine learning algorithms for an endpoint is now an automatic process that takes place when machine data is uploaded to the resource at "/api/v1/targets/localfile" and a POST request is sent to "/api/v1/targets/training".
And, instead of requiring users to setup SSH/remote credentials for DeepSentry to perform strike operations in response to suspicious activity users will receive a generated security report in JSON format they can utilize with private, internal orchestration tools.
Since strike operations have been removed from DeepSentry, the usage of DeepSentry is no longer considered a utility of U.S. Military Communications Equipment as defined by U.S. Export Controls. In addition users can't download any proprietary software from DeepSentry so the use of DeepSentry is not bound to U.S. Export Controls.
A remnant of the old design
A remnant of the old design is still in place because I haven't settled on an alternative to replace it, that's endpoint registration. The API would be much friendlier if endpoint registration was an idea in the documentation rather than a requirement for an endpoint to use the API. I'm currently working on that problem although it hasn't been added to our page for Bug Tracking & Known Issues
I'm aware there isn't a TLS certificate setup for this website. This website resides in a static bucket on AWS S3. AWS CloudFront is responsible for serving the TLS Certificate for S3 buckets. The real issue here is that AWS CloudFront doesn't work well with dynamic content in S3 buckets, it could take up to 30 days to update existing pages over their CDN. For the most part this website is static content aside from the blog and bug tracking. I would like to wait unitl I've finished writing the documentation and the updating the other content of the website before setting up the TLS Certificate.