List view
Deep learning approaches to incident detection based on higher-level features extracted from summary reports about forwarded & audited events: e.g. feature matrices of possible event features (e.g. AUDIT, FORWARD | REPORT, SUCCESS | FAILURE, ...|TRAFFIC|LINUX|WINDOWS|...) and occurrence by e.g. session ID).
Overdue by 4 year(s)•Due by June 4, 2021Supervised ML approaches to incident detection based on summary report classes identified (declared, discovered, etc.) in the modelling of threat vs. benign incidents in scheduled test scenarios.
Overdue by 5 year(s)•Due by December 31, 2020Rule-based approaches to incident detection applied to summary reports about forwarded & audited events (e.g. feature matrices).
Overdue by 5 year(s)•Due by November 6, 2020Serves a single-page UI to view incident alerts & summary report trails at the `/` route served by presentation tier.
Overdue by 5 year(s)•Due by October 2, 2020- Overdue by 5 year(s)•Due by September 4, 2020
Deployable as a standalone web application serving DSL requests at the event forwarding & reporting routes served by the application (e.g. constrained-SQL transaction requests).
Overdue by 5 year(s)•Due by July 17, 2020•1/1 issues closedThe presentation tier should serve a report route that allows request summary reports about each type of forwarded & audited event by combination of features (as feature matrices or probability distributions). In a follow-up scheduled deliverable & release, it should serve forward routes to attach summary reports to an incident associated with a triggered alert, forwarded to an incident management & response platform.
Overdue by 5 year(s)•Due by July 3, 2020Model a request DSL using the free monad of a DSL request functor, for event forwarding reporting (+ constrained SQL queries, abstraction over DBMS backend(s), DBMS access control, DR/BC, risk management, CIA of data, replication/failure, scalability, and so on). Data-access performance risks must be audited and assessed prior to the release, with appropriate risk mitigations where assessed performance risks are a roadblock to the success completion & continuity of the project, and issues tracked for assessed risks otherwise. The performance of the data-access tier w.r.t serving concurrent requests from multiple clients should scale with the number of clients (e.g. employing a separate DBMS instance for each client specified in a authorization / destination ID specified in DSL requests): it should be able to serve |e.g. 600| event forwarding requests per minute from each client, while serving |possible event features| requests per minute from |expected production instances of front-end application according to e.g. DR/BC plan & deployment guide|, to consider this risk mitigated. It should employ DR/BC & OWASP Top 10 security risk mitigations, such as [replication/failover](13), [authorization/access control](14), and [logging/monitoring](15) of audited DSL request events during the effectful execution of requests.
Overdue by 5 year(s)•Due by June 5, 2020•2/2 issues closedThe application tier should be deployable as a self-contained binary executable for a variety of platforms and architectures. It serves route(s) to allow clients to [forward](5) processed security events in the body of POST requests (e.g. traffic/gateway events, Linux Auditing System events, Windows Security events, as well as e.g. tier-to-tier audited events & alerts). Moreover, it serves route(s) to allow clients to request statistics reports about the number of forwarded & audited events [by](5) source, session, destination, log, schema, feature, instance, period, and duration in URLs of GET requests; a more robust [report DSL](16) is intended to be implemented as part of a [follow-up](/markfarrell/3tier/milestone/4) release & deliverable. This scheduled milestone & deliverable should be accompanied by a performance & security risk assessment (including a SQLi vulnerability assessment) prior to its tagged publication; [automated risk assessment](22), e.g. towards a self-contained SQLi scanner, are proposed as part of a future deliverable & release. Modules should be implemented to parse raw Linux Auditing System & Windows Security events in JSON format and moreover as [processed security events](5), with appropriate tests; all JSON object fields should validated to mitigate SQLi risks, e.g. that the field does contain a valid SQLite3 keyword in this release, and e.g. that the JSON object contains the appropriate field names for its Linux message type or Windows task category. More tightly constrained parsing/validation for the possible field combinations that can be included in each type of forwarded event will be implemented as part of a future deliverable & release.
Overdue by 5 year(s)•Due by June 19, 2020•10/10 issues closed