Daniel Byers

Adding new rules to enhance detection capabilities. Reviewing and tuning current content packs to ensure detections are up-to-date. Rules were written in SIGMA or in AQL, depending on the platform. Part of these responsibilities included purple-team processes, where red team would attempt to circumvent our detection logic and blue team would fine-tune it to broaden the scope.

Content developed was stored and maintained in a Git repository. This required us to follow standard software development practices, such as submitting Merge Requests of new content and reviewing those opened by others, following a strict checklist to ensure quality. In addition, content is tested for accuracy and false positives with automation written in Groovy and running on Jenkins. Our team has ownership of the release pipeline from research, through development, and finishing with publishing to IBM AppExchange.

Provided assistance for IBM's participation in the MITRE ATT&CK Evaluations for QRadar Suite. My role was to provide support for both the red and blue team responsibilities specific to Linux. This included liaising with colleagues across multiple teams, designing and deploying infrastructure to test, research regarding the tactics in scope, attack emulation and gap analysis of those tactics, and finally rule creation.

Produced reports detailing vulnerabilities of devices for CVEs in the CISA KEV list. This was a full report building on information by other research teams, including a proof-of-concept exploit that could be used to automate discovery of vulnerable devices. In addition to writing reports, I improved the build process by containerising the build tools and designing a cloud-based automation using Tekton on IBM Cloud.

Ensuring the sensor is up to date to protect customer’s environments against modern tactics, techniques, and procedures. This is achieved in two ways; passive monitoring that observes and captures interesting activity occurring on a host, and active scanning, which runs at periodic intervals to locate and detect malicious (or suspicious) states.

Writing the logic that implements the above research into the product. The code must be balance accuracy with performance, as the sensor needs to run under a wide range of scenarios. Part of the requirements of development is source control management and code reviews.

Code must be thoroughly tested, at the individual unit level and across dozens of Linux distributions and MacOS versions, taking into consideration the variations in how they operate. This process requires several tools; C++, Python, Jenkins, static analysis, and flamegraphs.

Keeping the sensor documentation up to date with new improvements. Writing tickets to explain the reasoning and implementations of research.

Brought in to manage the four interns that were employed to undertake the next stage in development. This included maintaining a roadmap for the project, with assignments for each intern based on their skillsets and interests. Additionally, scheduled weekly one-on-one meetings to track what progress has been made, and to provide mentoring if they needed any. Redmine was used as the project management platform.

The key aspect of the role was building the application from the proof-of-concept to a complete software product. Research was essential to facilitate the next stages of the product; the software libraries used to implement the functionality were open-source, but mature and complex. A lot of investigation was necessary to understand how they could be adapted to fit the desired result.

Maintaining the code base was a priority, ensuring it remained clean, efficient, performant, and up-to-date. This entailed managing code via a version control system, writing unit tests, and automating tests on staging environments to ensure software quality. Additionally, the team tracked progress using tickets and a clear roadmap.

The CEO had an idea that was suited for a Computer Science disseration, and tasked me with proving the feasibility of said idea. The internship requirements demanded a working prototype as the proof, which was completed in conjunction with my Masters end of year project.

Building a system that allowed for three independent third-party APIs to stay synchronized with the business (and each other) if a customer updated their information in the any one of those APIs. This was a very challenging task, requiring understanding several disparate architectures and how they communicated with outside systems. It required modifications to the system architecture to facilitate this functionality, which included defending those choices to management with accurate justifications.

Extended the test suite to reach the goal of 100% coverage.

Tasked with building a connector between the client’s WordPress website and a third-party XML API. This connector would automate a manual process whereby customers information was needed to be submitted to a partner. What initially looked like a simple connector in reality turned out to be a complex list of rules to massage the input data to the format that the API required.

Gathering requirements to facilitate a cross-team effort migrating data from different systems into one consolidated set. Had to learn and implement an Extract, Transform, Load (ETL) pipeline.

Functionality to faciliate between main corporate product and partner third-party API to incorporate a website builder. As the company was a cloud hosting company, they wanted to resell website generation for free as part of their product offering. This was implemented as a standalone Ruby gem.

Building a microservice to provide system/network engineers ability to dump logs via an API and view them as tables within a browser. Included calculated metrics and output format for graphing software.