Week 2 Posting – Handling SLAs, CVSS, and Vulnerability Scanning

Thoughts on Week 2: Handling SLAs, CVSS, and Vulnerability Scanning In Week 2 of this class, I learned the basics of vulnerability management and how formal agreements and frameworks help keep things running smoothly. We began by talking about Service Level Agreements (SLAs). These are more than just contracts; they tell you what to expect when you work with third-party providers in terms of uptime, incident response times, and security responsibilities. I learned that SLAs are a good way to hold both organizations and vendors accountable, especially when they are handling sensitive data. I also learned how to use vulnerability assessment tools and what to do after I pick them. You can't just pick a tool; you also need to set the exact limits of your scans, make rules, make a schedule for scans, and decide if authenticated scans are needed. I learned that pilot scans are important to reduce false positives and that the results of scans should be linked to a ticketing system or configuration management database. This integration changes raw data into tasks that can be followed through to completion. We also looked into the Common Vulnerability Scoring System (CVSS). This framework gives vulnerabilities a score based on how easy they are to exploit and how bad they could be, using base, temporal, and environmental metrics. I learned how companies choose which vulnerabilities to fix first by learning about CVSS. A problem with a high score on a critical server needs to be fixed right away, but a problem with a lower score on an internal system can wait until later to be fixed. Finally, I learned about vulnerability feeds, which are curated sources of information that always give you the most up-to-date information on new threats, CVE IDs, CVSS scores, and how to fix them. Teams can stay ahead of problems by staying subscribed to a reliable feed instead of waiting for them to happen. This makes sure that new risks are handled right away. In general, Week 2 made it clear how formal agreements, structured assessment practices, and standardized scoring systems all work together to make a good process for managing vulnerabilities. When I work with vendors or team members, I feel like I can better figure out which security issues are the most important and make my expectations clear.

Comments

Post a Comment

Popular posts from this blog

Week 1 Posting -

This first week of BSIT380: System Hardening and Network has really changed how I think about cybersecurity. The class started by comparing it to a big sporting event, where both teams study their opponent before the big day. That comparison helped me see why threat data and intelligence are so important: you can't protect a network if you don't know who the attackers are, what they want, and how they work. We talked about today's threat actors, such as nation-states, cybercriminal groups, insiders, and hacktivists. Each one has its own reasons for doing what they do and ways of doing it. I also learned that threat intelligence is more than just reading about attacks in the news. It means getting information from a lot of different places, looking for patterns, and using that information to make the organization's security better. The readings talked about the frameworks and threat research sources that analysts use, as well as different ways to model threats that hel...
Read more

Week 8 Blog: Ideas and Tools for Automating

This week really drove home how important automation is in today's cybersecurity work. One of the most important things I learned is that attackers are already using automation to launch network-speed attacks on a large scale. If defenders only use manual processes, they will automatically fall behind. Security Operations Centers (SOCs) use tools like SIEM and SOAR to find, connect, and respond to threats much faster than a person could do it alone. Automation doesn't take the place of analysts, but it does make them better at responding quickly and effectively. I also learned that playbooks and orchestration are very important for making sure that responses are always the same. Instead of responding to each alert in a different way, businesses can set up structured workflows that automatically collect logs, add information, isolate endpoints, or let the right teams know. This cuts down on alert fatigue and makes responding to incidents more consistent. It's important to t...
Read more

Week 5 Blog — Software and Hardware Assurance Best Practices

This week made me realize that security isn't just about making the operating system stronger; it's also about protecting everything from the code to the firmware and hardware. My biggest lesson about software was that security needs to be built in from the start, not added on later. That's why it's important to have a good SDLC and follow safe coding practices, like checking input, using the least amount of privilege, and testing early. It also made sense why third-party libraries and tight deadlines can be a problem: one weak spot can become a real vulnerability. I learned why firmware is so important on the hardware side: it controls low-level functions and is found in almost every device, such as servers, embedded systems, and IoT. If firmware isn't kept up to date and managed properly, it can break everything else. I also learned how hardware can help with a "root of trust," which is useful for things like secure boot and checking the system's in...
Read more