enterprise security - automation - zero-day vulnerabilities - security and incident response - asset scanning - ticketing pipeline - scheduled job
After much deliberation, I finally settled down on a project scope. The idea was to assist in uplifting the Vulnerability Management Program for the current quarter. We decided it'd be best for me to contribute to the zero-day vulnerability ticketing pipeline.
All in all, I thought the whole idea was very intriguing, as there wasn't any sort of process in place. In other words, I would be the first to directly participate in the efforts to solve said problem. So to give a quick overview, the current process of identifying zero-day vulnerabilities that affect corporate assets and the process of notifying the right team to ideate remediation processes were ad hoc, as in done manually only when needed. And that's where I came into place - I was to utilize the API of a threat intelligence platform to cross-check with affected corporate assets, and ticket out the necessary details to the responsible team.
After dabbling more in-depth into the problem, I suggested that it'd be best to come up with two parts of a solution - an interface that could trigger the pipeline manually, and a scheduled job to perform the cross-check on a regular basis. What started off as a rough draft finally kicked off into a full-blown project.
I created a wrapper that will directly interact with the API itself, as well as perform all the necessary configurations in terms of authentication and error handling. Next, I created a ticketing helper class that is to perform the necessary logic, such as cleaning up the response from the API, parsing and reformatting the fields to be compiled based on similar categories, cross-checking with corporate assets, and creating tickets to notify the responsible teams with the necessary information needed. Next, here lies part 1 of the solution, the endpoint - the ticketing pipeline will be triggered automatically based on the input parameters of the user. Lastly, I was able to wrap up part 2 of the solution, the scheduled job - the ticketing pipeline will be run regularly based on a CRON job.
And suddenly, it was 2:00 PM EDT. My account got deprovisioned instantly, and my summer internship at Box had officially ended. I couldn't help but to feel so very empty, not to mention that I had to physically return all my work hardware (work laptop, charger...) so my backpack no longer had weight to it; Empty though it was just two-ish weeks that I went to the office in person. And during those two weeks, I tried to take it all in - I reserved a desk every day, brewed up a cup of coffee every unreasonable trip to the snack area, dropped by the lunch room to visit the company's CEO in his youthful moments, and stooped to every lounge area on each floor. And by snapping one last photo at the office, I packed up all my regrets and tears and boarded the next train. Indefinitely, I left feeling disarrayed because everything ended in EDT, thus 2:00 PM rather than 5:00 PM, I wanted to formally show my gratitude to everyone who helped me throughout my time at Box, I wanted to make my final corrections to my project, I wanted to fill up that exit survey form (Dear recruiting team, if you're seeing this, I'm so sorry), I wanted to...
Thankful for the experience anyways, and here's what I learned:
The importance of code infrastructure: a corporate environment means that there are teams. Programs should always be structured to be transportable and reusable. Think of functions and classes - parts of the code that will indefinitely be reused should be containerized. What started off as a two-file program for me, turned into 3 files, 1 folder, and 2 repos, and that's just a glimpse of it.
The importance of documentation: a big part of my responsibility was to be able to present my solution, and to convince that it benefits the team. Think numbers and metrics when showcasing your ideas. On the other hand, assume that no one knows your idea inside out, so document your progress and add in all the necessary comments: what it does, how it works, where it lives, when it runs, and most importantly, how to fix and improve it.
The importance of good coding ethics: I was exposed to how corporate environments produce code, from making a PR, testing on a local Docker container, building a Jenkins pipeline, code reviews, and my ultimate fear - merging the PR. I was so impressed with the processes set up, the workflow itself, and the teams doing it all. And for the first time ever, I was exposed to the word "linting".
Be proactive and curious: One of the things I heard most throughout my internship was that I asked the right questions. And because I asked the right questions, my idea was able to come to life. In fact, it was much better than what I initially had in mind - I was able to implement extra functionalities to my program such as identifying duplicate tickets and reducing noise from the automation. I learned that the right people would always be willing to help, but I needed to reach my hand out first.
Deliverables and sprint cycles: I learned about goal-setting in a corporate environment, sprint models to meet quarterly targets, and how approvals are granted from the top-down. It opened my eyes to how the team reports to the management, how performance was recorded, and how it always has to align with the company's values.
Box employees pride themselves on the company's culture - I finally know why. The train director announced our departure from Redwood City for the very last time (in my case, I mean). The Box logo disappeared from my viewpoint, but its warmth resonates within my heart still.
Dedicated to everyone at Box Inc.
Comments