If you’re looking for something to do with Perl (or Python or other scripting languages you’d like to play with), you can always make a quick and dirty port scanner. For instance, like this SSH port scanner script. Just looking at the code, this isn’t something that uses a specific SSH client or anything; you can just change the port to create a different scanner.

And this can be built upon very easily by searching for other examples like a more robust port scanner in Perl. You can scan more ports, a list of ports, maybe replace the random IP address with a static list that you supply.

Even better, get a port scanner on every system in an environment without having to rely on an installed scripting environment…enter PowerShell! Yes, start playing with port scanning using PowerShell scripting. This is arguably a bit better than installing the Telnet client on current Windows server boxes every time you want to troubleshoot network connectivity.

Is this useful? Absolutely, from both offense or defense, you can find specific things in an environment that maybe run on a weird port or common ports like SSH. Scan your network space from your own admin VLAN to find lost devices that aren’t in inventory but weren’t properly decommissioned, or maybe that test Linux VM someone stood up last year that was supposed to be temporary. Tools like this can be used to test and validate firewall rules, which always sounds easy in practice, but is not necessarily so when you really get deep and dirty with it.

This can also be used to test security detection processes, like network IDS/IPS. Catching sequential or even random (but large volume) scans should be something easy to accomplish and test. You can even add some waits/pauses to the script to slow the scan down and watch behavior of your IDS/IPS versus time it takes an attacker to get useful information off your network. Need to test your IDS/IPS for an auditor? Creating easy, but relatively benign alerts in a few different ways is useful (like triggering a WAF with a GET to cmd.exe or something).

I’ve been in some job interviews in recent weeks, and gathering a list of qualities that information security professionals should have. Ingenuity, problem solving skills, knowledge and aptitude, detail oriented, analytical skills, healthy skepticism, team player, autonomous, enthusiam, empathy, having a good heart (these last two deserve their own posts). All of those are highly important, even required. But I think there is one quality that I think leads many of these: integrity.

Security is tough.

You don’t need security without the insecurity, and as such security will always be behind the curve.

You’ll always be fighting against agile bad guys and always behind, but you’ll also always be fighting users who want 100% convenience. And you’ll always be fighting against other pulls for business budgets and money. And always fighting the growing complexity and chaos.

It takes integrity to be in security. And it’s more than just not looking at the CEO’s emails when you have access or passing along trade secrets or posting security holes on social media or keeping quiet about an HR investigation into harassment claims.
Integrity isn’t surprising as an important quality in security, as it is also an important quality for life in general.

It’s also about admitting you don’t know something and the subsequent quest to learn it, rather than faking it and losing credibility.

security is difficult.

These teams need to know what is important to the business and how to balance user access/convenience against security and budgets. That’s a high degree of business acumen that is required.

Security also needs technical chops in all areas, from data management to networking to systems to desktop to programming so that they can provide guidelines and mentoring on how to be more secure. That’s not something where a desktop person can come in and immediately be effective without knowing how network infrastructure or server management is handled or has never spoken to developers before. They also need to back up their theoretical anecdotes with evidence of successful attacks and defenses.

Security also has to know how to handle people, as they are always the weakest link that need to be educated and incentivized (I prefer incented as a word..) to know and do the right thing, from non-technical employees to the deeply technical senior IT members.

Security needs to be objective with technical logic, but subjective and creative to keep up with innovative attackers who find and leverage new issues weekly. It’s even sometimes artful in ways to detect and prevent attacks.

Security needs to be rigid and stick to compliance standards and expectations, but also flexible to the ever-changing world, business, technical solutions, and attackers.
Security needs to be confident in their solutions, but also humble enough to accept subject matter expert feedback and suggestions.

I love this profession, even if it causes me to take an extra drink some Fridays. The challenge is intoxicating even as it is frustrating.

Saw mention of a post over at CIO: 5 Security Practices Hackers Say Make Their Lives Harder. Ok. It seems like every security practice should make their lives somewhat harder. The 5 items trend largely towards password and privileged account protection, which isn’t surprising since the survey was conducted at Black Hat USA 2016 by Thycotic, a vendor of password and account management tools ( or Privileged Account Management [PAM] for the fancy). And I have used and generally like their Thycotic Secret Server, so I have nothing against them. I just generally have issues with vendor-led statistics.  [As an aside, I consider Thycotic a sort of third level solution for any organization that has to manage privileged accounts. First being nothing, written, text files, or Excel files with password protection. Second being a PasswordSafe, keePass, or even LastPass sort of user/group password management tool. And third being something enterprise-ready that you’ll have to pay for, though not exorbitantly, like Thycotic.]

So I headed off to see what this survey was all about. I found a copy sitting over at SCMagazine: the 2016 Hacker Survey Report. Mysterious! Unfortunately, the survey pdf itself shows nothing of the methodology of the survey or the questions asked to get those 5 items that make hacker jobs more difficult.

Are the items wrong? Not really. Account security is highly important, from admin to end user. Access escalation and end-user phishing are strong topics for IT security in 2016 (along with cloud security and anything to do with PowerShell).

I just always get skeptical when I see self-serving vendor-provided surveys and information.

Edit: I actually just saw over LinkedIn that the survey pdf is now available from Thycotic if you want to submit some false sales information (no real verification or checks to download). It’s the same pdf as linked up above. And it’s still really not that interesting.

Metasploitable 3 is out, and there are some differences from the previous version. The vulnerable system is a Windows box this time, and instead of just downloading a VM image and firing it up, the author(s) have decided to leave it up to the end user to package the VM. This adds a little complexity for us, so I thought I would walk through the steps it took to get me up and running. This really wasn’t terribly difficult, but this is my first time using vagrant/packer and it’s been a long time since I used VirtualBox. Hopefully I remember this all correctly! I did this install on a relatively clean, patched Windows 7 64-bit laptop. I did not track when I had to run installers or cmd windows as Administrator.

• Make sure the system you’re installing this to has Internet access, and it’s not just to download the installers. There are various downloads that happen during much of the execution of vagrant. I know. That’s strange to ask security geeks to just trust, but that’s the reality of this method of deployment. If you want to watch it and authorize each access attempt, make sure you have some tea/coffee nearby and a book as my install took about 20 minutes or so.
• Download Packer by following its install instructions. Don’t forget to set the PATH variable. I just put Packer inside Program Files.
• Install Vagrant 1.8.1. The Metasploitable3 instructions discuss a problem with 1.8.5, so I didn’t even try it. This installed into C:\HashiCorp\Vagrant.
• Install the Vagrant Reload Plugin. Basically just run $ vagrant plugin install vagrant-reload from a cmd window.
• Install VirtualBox 5.0.10.3. The latest version is 5.1.6, but vagrant 1.8.1 during execution will want 5.0.10 and attempt to download/install it. That process never succeeded for me, so I installed this manually.
• Install Microsoft Visual C++ 2010 Redistributable. During vagrant’s execution, there was a point where I was stopped and waiting for an SSH connection that never happened (I believe that’s where I needed this). Installing this got me past that hurdle. Note that I’m linking to the 64-bit version.
• “Clone this repo and navigate to the main directory.” We get choices here now. You can just download (“clone”) the zip from the GitHub website and call it good. Or you can download and install Git or Github Desktop and make an account. I chose that latter. After I installed GitHub Desktop and created an account, I opened a Git shell from the Start Menu, navigated to where I want to stage my pre-packed VM files, and issued, git clone https://github.com/rapid7/metasploitable3.git This created the “metasploitable3″ folder for me, so I didn’t need to manually create it. For me, this was c:\users\michael\documents\github\metasploitable3\”. The Git shell, incidentally, will open by default in your user documents folder.
• Next, run packer build windows_2008_r2.json while in a cmd window inside the folder you cloned metasploitable3 into. This will take a while. I don’t recall having any issues at all with this step.
• Now, run vagrant box add windows_2008_r2_virtualbox.box --name=metasploitable3 to add the box to vagrant.
• Run vagrant up to start the new VM. This will run a bunch of scripts and you’ll see the box appear and reboot several times if you happen to have VirtualBox running at this point.
• About 10 minutes into this process, my box disappeared from VirtualBox and the vagrant window showed a bunch of “from” lines. At this point, vagrant has hit an error and walked a bunch of stuff back. Scrolling up, I found an error from winrm about having more then 50 concurrent operations. (“The WS-Management service cannot process the request. This user is allowed a maximum number of 50 concurrent operations, which has been exceeded…WinRM::WinRMWSManFault“) That sucks. Being new to vagrant, I didn’t really know how to fix the scripts for this error, but I did know how to fix this if I could get into the VM while the scripts were running. I ran vagrant up again and watched the VM console in VirtualBox. After the first reboot, I was able to quickly log into the box (vagrant/vagrant) and run this command: winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="500"} to set concurrent operations to 500. Success!
• Save the VM state. I don’t want to do all of this again any time soon, so I saved the VM state so I can keep it in VirtualBox and restore state as needed. Now, I can just right-click my new VM and choose Start whenever I want this system up.

From here, I believe the default settings for VirtualBox allow for NAT connections, so that my Metasploitable3 box has access to the Internet and my own network, plus my network systems can talk to this box. I may have just set this without thinking, and it’s not default. If you’re not on a private network, I suggest keeping this networking to host-only, and instead just install a kali linux or other pen testing VM into VirtualBox.

If you want to use this box inside VMWare or another hypervisor, export the Virtualbox VM as an Open Virtualization Format (OVF or OVA), which VMWare will recognize.

Is this a cool way to distribute a VM? It is if you’re familiar or comfortable with all these steps, probably more so if you go all devops and deploy systems using any sort of container/packer process or you’re a developer that shares VMs a lot. But I’m glad I don’t have to do all these steps for most VMs that I download. For instance, standing up Metasploitable2 doesn’t even require a post since it’s just a download-open-start process. Also, this is sort of what you need to do for a Windows VM these days, unless you want to license them on your own.

Aside: I have no idea how WordPress automatically chose to make the code lines special boxes. Neat, I guess. And I don’t like having to put a check mark into each link to open in a new tab. I do this stuff faster manually typing the dang tags…

This is an old compilation I made for a future post that never materialized. But I like the list, and have decided to just post it unfinished.

I’ve long compiled a list of what I would call “security laws.” These “laws” are principles that cyber security experts should be aware of, or outright aligned with. Some of them I’ll explain in more detail, but others I think speak for themselves. Getting oneself hung up on any of these laws can cause insecurity.

There is no silver bullet to security. – The IT and information landscape is so large, divergent among entities, and dynamic, that there is no silver bullet device, technology, or set of best practices that will offer a state of security.

Security events *will* happen. – Likewise, be aware of intolerance to the inevitability of a security breach. In other words, be aware when your culture or posture exhibits symptoms of assuming security events won’t happen.

You cannot “win” the security fight, but you can survive.

You can’t prevent/address what you don’t see.

Security is a cost; it rarely directly enables business. – Security enables business in only two conditions. 1) Your core business is security-related. 2) The business would absolutely not have been possible without the security, i.e. regulations, requirements, customer demands. Avoid twisting and tying that second condition into knots. (present edit: I’d also now add that security can be an enabler if it helps protect a business competitive advantage. And yes, I actually consider this bullet item to be discussion fodder.)

Compliance and regulations only help to achieve a common denominator; companies are economic entities and will tend to only do what is necessary to comply. This keeps overall security low. Structure your security posture in a way that compliance and regulations are met as a convenient result, not as the end goal of the posture. (present edit: This can also be discussion fodder.)

Security does not exist and has no need if there is not insecurity.

Trust, but verify. Or don’t trust, and verify.

Security bugs cost more to fix the longer they are allowed to exist.

Never assume, always check.

Management by fact trumps management by belief.

As humans, we make mistakes. – From errors in judgement, to misconfigurations, to mistakes, to creating fallible products.

Defense in depth, security in layers.

If you can’t do the fundamentals of security correctly, you won’t do any better with complex, automated tools. (Present edit: I have always found this tenet to be important, and it’s something I always tried to interview new hires for. If someone knows the fundamental building blocks, then they can wield and understand the big power tools…or the weaknesses they have!)

Customers do not pay for invisible security that they can neither touch nor see.

Attackers have far fewer laws, ethics standards, and constituents they need to answer to. They don’t necessarily need change mgmt and various layers and people to approve changes or operations. Attackers maintain an agility over slow-moving business due to the nature of business and large groups of stakeholders.

Security geeks with a strong security mindset will always want the best protections. No company can afford the dreams of a strong security geek. Tempering this tendency to consider the issue as a 0 or 1 is part of the battle of a security geek. Some call this battle the “alignment of security with business” or the move of security geeks to being more “non-tech-friendly.” There *are* exceptions, especially if you’re being paid to give the extreme security answers, even if you’re not always given the budget green light. Know when you are part of that role. This might be called reconciling your security ego and security id…  (present edit: Basically, I’m trying to say that the security in a business is a constant balance of the grey area between perfect security and no security. You put 10 security geeks in a room and ask them to design perfect security, you likely will get the same answer from all 10. But ask them to fit security into Company XYZ, and you’ll get 10 wildly different resultant answers.)

Do not let the media solely guide your security culture. – Cyber Security is the new darling of mass media. Since security is not absolute and will always be broken and security at some point has to trust something else without assurances, then security will always be potentially broken (no matter how insane or movie-script-like the scenario is). Likewise, security will always ultimately depend on fallible people. Thus, the media will forever have something to wave around when it comes to security, or insecurity incidents. And thus, the media should not be our guideline or focus when it comes to evaluating our security stances. The media only provides for measurements of security theater (which itself is important to keep in mind, but does itself not convey much real security value). Similar to “reality television,” media loves to point out failures in security.

Security is real-time, both in technology and actual incidents. Try not to live in the past, with past technologies, and only aware of past techniques.

Don’t forget the past. The past is a basis for our fundamentals, and the fundamentals still suck.

You WILL be the bad guy. Because for every security decision you make, someone can come back to you with, “But you *caaaaan* do it this insecure way, right?” Most often, security is a matter of a person or group of persons drawing a line. We love it when we can say something is not possible unless you do it secure, but hate when we only have “best practice” or “policy” or “security” as the only reason.

People (Users) follow the path of least resistance. If they’re allowed to do something, they’ll do it. People won’t police themselves when their convenience is impacted. They’ll keep doing it until you discover them doing it and provide some punishment (like parking in the visitor’s stall once…and then doing it until threatened otherwise.)

The packets never lie.

User education is a long-term behavior changing initiative. Don’t expect radical results in the short-term, but still take any moment you can to provide knowledge and advice to others.

I wrote this post as a draft several years ago. I don’t plan to finish it, and honestly the moment has passed even more than it was passing at the time of writing this. But I like what I was doing here and wanted to preserve it and not keep it as a forever-draft.

I noticed a bit about community and blog commenting and such over on the Securosis friday summary last week. It sparked some thoughts I wanted to get down. I’m going to steal the part that got me thinking:

Back when we started the [Securosis] Friday Summary the world of blogs and social media was much different. RSS feeds were the primary means by which most of us sucked down our news, and we tended to communicate through cross-blog links and comments….
Since then a lot has changed. People blog a lot less, and there are far fewer discussions across blogs commenting on each other’s posts. Much of this has gone over to Twitter – which is sometimes good and sometimes bad…

First, my own observation mirrors theirs. I still get a lot of my news and discussion from RSS feeds. I still personally comment a ton, but I will say that I do see a lot less commenting overall on other blogs, both from readers but also from the authors. And much of the (stunted) live discussion takes place on Twitter, and any breaking news will come first from my Twitter feed updating in front of me (huge benefit!). There’s no arguing that at all. The downside is how ephemeral Twitter is. If you’re not outright watching the feed as it goes, there’s really no scrolling back to catch up on your day. This reminds me of days on very busy IRC channels years ago.

I wasn’t involved and I don’t know them personally, but I remember times when the AShimmy blog would get into back-and-forth blog postings with other blogs. These days, this same situation will occur in Twitter. And if I’m not there to watch it, it’s gone and the group dynamic has missed me. Likewise, if I’m not actually already following those participating parties, I’ll miss it (something that irks me to absolutely no end with Twitter). This means you’ll involve the people who already know and are present at the time, but cross-blog discussions mean someone can watch and get to know the authors or even participate a few weeks later. Pulling new people into the discussion can work by accident with blogs, not so much with Twitter. (present edit: I’ve actually come to disagree with some of the Twitter feelings at the end of this paragraph.)

I’ve long been a proponent of web forums; I still think they’re the ideal place to share discussions and build community in an online world with people of similar interests. I’ve long been a consumer of those services (I still comment quite a lot in the security arenas!) and even been a leader in a few (online gaming communities around Quake and UT, primarily). So here are some “community-building observations” that apply to blog commenting and social communities and not just web forums. (I’ve made a similar post in the past.) (present edit: I still believe in forums, but their time is also passing by now. It’s hard to be a contributing member of more than just a couple forums or communities, and these days you’re left with Twitter, Reddit, maybe some LinkedIn or FaceBook conversations, but beyond that it’s difficult to find the time to keep up. I think what I was really going for here, was basically what Reddit has become today: a partly-ephemeral threaded community board.)

1. Always respond. – If someone posts on your site/discussion/forum/blog post, always respond in a positive and public manner. Others that see that interaction will know you’re present and it may encourage future participation. Likewise, it you’re not present, unless the community has taken off and can guide itself for periods of time, it will absolutely depend on you and reflect your participation. In one UT forum long ago I earned the reputation of always replying to almost every topic. This was true, but while I don’t think I was all that integral to the community being a success, that sort of behavior does not hurt it. It may in fact give more character and actually spur further discussions!

2. Don’t dominate discussions. – By this I mean don’t dominate individual discussions and quell other people’s ideas or opinions. You can be the one who dominates new topics and bringing them up, but always make other people feel like they’re important, respected, and contributing. No one likes a know-it-all, and no one especially likes one that knows he’s a know-it-all and pushes them on others. Be a bit vulnerable, ask for ideas, and if someone else ends up being a dominant presence in the community, that is actually a good sign.

3. Don’t let stagnation develop. – Nothing kills a community more than a sudden absence of new content or discussion or topics. Do this, and you might lose everyone you had before and have to start over from the beginning, only with the stigma that your community died once and may die again. Even if you’re the only one posting, keep posting.

4. Embrace anonymity. – Especially in a security-related community, you really need to embrace anonymity. We’re a hyper-paranoid and privacy-sensitive group of people, and if you want a solid cross-section of persons talking frankly and openly, we need to embrace anonymity. Sure, they can use their real names and reveal their employers or maybe leave themselves open to be tracked down, but that needs to be their decision. Also, don’t ever deride someone for a valid opinion just because they made it with the veil of anonymity. You might have a point, but so do they. Embrace that. (Likewise, keep in mind your female participants who may have a wholly different experience in digital life than their male counterparts.) (present edit: This is becoming less of a thing. People use their real names far more often now thanks for Google+ and FaceBook and even Twitter to a degree. But also, most of us end up meeting each other through job or con networking anyway. Still, some of us definitely still prefer the old school screennames…)

5. Reinforce the hardcore. – A nicely growing community will likely have one or more “hardcore” persons who participate far more than others; maybe they comment a lot, maybe they enter lots of discussions, maybe that start lots of them. Either way, recognize them when you have them, and make sure you listen to, include, and encourage them. In a way, having some “hardcore” participants in your social circle you have is a way of measuring success. If someone regularly comments on your blog, encourage them or say hey via other channels, or whathaveyou. This doesn’t mean walk on eggshells around them because they’ll make or break you, but just recognize that they’re integral to keeping things from being stagnant and in driving further discussion and community growth. I think many, many services online are made or broken by their hardcore constituents, and they really need to be carefully tended, and yet not over-tended… Bottom-line, just the fact that you have to deal with this group on any level is a good sign.

6. Encourage and welcome the new blood, but let them control the exposure. If they reach out, reach back. – Don’t force new people to introduce themselves, but embrace it if they do. Never let an introductory presence go unnoticed. Always respond, and ask engaging, interested questions. If they express interests or expertise, probe that and make them feel valuable or interesting. But don’t force it. Some people will lurk for a considerable amount of time before participating, but others will dive right in with newbie questions. Embrace all approaches and positively reinforce them.

7. Actively draw people in. – You don’t build something and expect people to find it. You have to go out and draw people in. If you want people to comment on your articles, you need to get them to first see your articles, and then demonstrate that you’re interested in comments. This usually means commenting on many other blogs in turn. It takes a lot of effort and time for a community to be self-sustaining as far as new members goes. Again, your hardcore will help with that, as will just being a positive place for people to participate in, and suggest to others. But for a long time, you’ll need to funnel the people in, either with compelling content or brute force. [In my gaming sites, I had it easy with well-respected gaming tournaments bringing in people, so this part was easy. In something like BackTrack forums, their software brings people in.]

8. Embrace off-topics. – Just take a look at any forum for even niche topics, or any group of Twitter followers and you will see that “general” or “off-topic” discussions often will be the busiest places in a community. Let people fraternize and talk about other things, and give them a place to do so without watering down the on-topic stuff. I also consider the health of the off-topic discussion area to be an indicator on the health of the community.

9. Practice design/navigation simplicity. – This probably applies directly to web forums, but please for the love of all that is pure and sweet, keep things simple. Don’t make 20 nearly empty forum boards for various topics. Make 3 (on-topic, off-topic, site help) or even less. I really desparately hate, as a new user, trying to find where I should be going. Growth of sub-topics and separate forum sections should grow organically and only as-needed for the community. Only make a new section if there is already a need to populate that section with content that is getting in the way of something else. This helps make sure you don’t wind up with 1 forum with traffic and 15 stagnating ones; a quick glance by an outsider will reflect more stagnation than use.

10. Be clear and consistent with your content policies. But be reasonable. – Primarily I intend this advice to be about images and avatars used on the site, and primarily to make a site viewer-friendly (safe for work, safe for kids, safe for family…). Let people be themselves, but make sure your site is viewable by the people you want to attract during times they are available to interfact. For a security/professional board, that likely means being work-friendly, so no thong-clad avatars nor signature smiley banging another smiley. Letting this get out of control early is a bad deal, and letting anyone (even your hardcore group or best friend) bend the rules too much is asking for trouble in your community.

11. Be careful when dealing with abusers. – Don’t start a ban-war with abusers or start moderating and editing their contributions. Let them know where they stand. If you have a mature community and someone starts acting up, the group should self-correct them, or if that fails, an admin making the rules clear should fix things. Just be careful making a martyr out of someone or creating an “us against the unfair admins!” situation. This is probably the most difficult thing to dance around when administrating a community, and is largely inevitable. But for those of us in business and security, it shouldn’t be an entirely foreign concept.

I wrote this post as a draft several years ago. I don’t plan to finish it, and thought I’d just publish it out now. This is not really complete, but I did fill in a few gaps. Also taking the time to hate on formatting things in WordPress…nested bullets are making me swear more…

I’ve spent some time tuning a SIEM as part of my day job. I thought I’d share the general steps to do this. Sadly, I can’t be too technical without becoming specific to the tool(s) I use, but I can at least outline the general concepts.

1. Gather logs from your devices/apps into your SIEM.
   This is typically an easy process, and every SIEM vendor will tout how easy it is. Don’t be fooled, this is easy by design, and not because their tool is particularly easy. It’s easy to suck in Windows logs, Linux logs, and even easier to catch the flood of syslogs you can send to the SIEM. Vendors will always tout how you can be up and running (often they will say, “gathering logs” without letting that sink in that a SIEM does more than just “gather logs”) in 10 minutes, a half hour, an hour, or a few hours. The hardest part is just finding all the logs you want to send to the SIEM.Assume you’ll be adding new logs as you go for devices you either overlooked early on, forgot about, or didn’t even know you had (high-availability pairs, dev environments…). And make sure to devise a plan to ensure that new devices get discovered or configured per a build process to get into your SIEM.
2. Make sure your SIEM understands and adequately parses the common logs you send it. Just because a SIEM can suck in the logs and archive them away, doesn’t mean the SIEM is configured to parse out the contents and make decisions on them. Most common devices and sources are fine, but some of your more uncommon devices aren’t going to be set up without special effort. You can get assistance from the vendor, but often they will tell you, “You tell me what you want, and I’ll set it up for you.” So…make sure you know what you want! Your time is usually better spent looking at the logs you get, demonstrating the activity you want to alarm on, catch the log, figure out what is unique about it, and then making your own alarm based on that uniqueness. Repeat ad nauseam.It should also be mentioned that you need a process in place to make sure your SIEM is still working properly and that logs are still showing up. It’s fine if you event on incoming logs that indicate badness, but are you looking for a total absence of logs as well? Hopefully your SIEM can raise these issues to you in more than a dashboard you have to eyeball manually.
3. Tune out the noise as much as you can and tune in to what you really want to know about.This part really forces you to think a little bit like an attacker and what she will do against your devices and what it will look like in your log files for various devices. This often includes two different levels of monitoring (maybe more if you decide that you get operational value out of the SIEM, rather than just security value):

   • events of interest in the logs
   • actual generated alerts/alarms that are sent to someone or raised for someone to look at

   This is also a very subjective piece of the puzzle, and somewhat artful as well, as you creatively ignore what you don’t care about, without accidentally ignoring too much. Probably will help to talk to your SIEM vendor on any tips they have to avoid performance problems with filters or log rules. Maybe their device will bog down when you give it too many filters, or maybe it will bog down when you don’t give it enough! For instance, if you log your VMWare ESX server syslogs, you’ll find that you literally do not need 99% of what you get sent.

   For every event you generate, ask yourself:

   • does this give me value towards alerting/detecting an incident in progress?
   • does this give me value towards guessing that there might be something strange happening?
   • does this give me value in finding more about events around an alert or incident?

   If an event is coming in all the time, and you know you’ll never consider it an event of interest, try to configure a filter for it. But be careful!!! For every filter you make, you create a blind spot. For instance, I have an account that leverages CatTools to log into various network devices and back up the config files, and this runs multiple times daily. I don’t ever want to know about these valid logins, so I ignore such log entries. But this means if an attacker gets into that account, she can use that account to get into the same network devices and I’ll be blind to those log entries. A better method might be to put a threshold on the frequency of logins per hour. Hopefully, though, any further manual things she does with that account on the devices will get flagged, since I really want to have an event for every actual command run on some devices (we’re not THAT big that I can’t just turn around and ask someone if they just did something…).

4. Close the gaps in your logs by getting those non-standard and custom logs understood by the SIEM. This is difficult to do, and probably dives deeply into one of two options:

   • Send logs to your vendor and wait for them to properly figure out the parsing.
   • Dive deep into the guts of the tool’s rules, and figure out the parsing on your own.

   The first option leaves you at the mercy of someone else, but they will certainly be better at it than you alone. The second option is a deeply technical and possibly very difficult task that will takes lots of trial and error and time. The reward is great, however, if you can master your chosen tool’s rules and how to cover stuff that isn’t covered by default.

5. Manage everything that is left in the alarms/alerts or events.If you have a SIEM in place and it is chomping on logs and generating alarms, but no one is watching it, you’ve effectively just made a complicated log management process that is only useful for forensic purposes, and does *not* raise awareness of security events or satisfy any goals for detection and response. If an alert comes in and it is an attacker, but no one looks at the alarms, then what was the point? I understand checklist security, but that doesn’t mean I will be satisfied by it.

   At a minimum, you should see positive, but non-incident hits from:

   • patches, assuming you also have a file integrity monitor in place, but at the very least a reboot should be noticed or maybe events for installed software
   • vulnerability scans should light up your SIEM (similarly, any pen-tests or other security reviews)
   • failed logins on various devices. No matter how much you tune, you can’t tune out every accidental series of failed logins and yet still be alerted when someone malicious is doing it. Sometimes it just takes one strange attempt to log into a network device as “root” that is important to see, yet you clearly don’t want to be told every time Sales Guy Bob mistypes his password three times in a row. You want to know when an account is locked out, but can’t tell from a SIEM whether that was again Sales Guy Bob doing it.
   • essentially, anything with a threshold value will be tripped someday. If you only care when a single device pings out to 50 different IP addresses, someday something will do that.
   • if you want to know that someone got into your border router and made config changes, you’ll also pick up authorized changes from your own admins.
   • user rights changes and account management are an every-day occurrence in a business, but it is common for an attacker to try to elevate their rights either on a local box or the domain. You should see hits for both. This includes new user creation.

6. Lastly, test your alerts to make sure you’re getting what you need, and learn from the computer forensics disciplines.Generate some events that you would want to make sure you pick up if an attacker either attacked your systems or actually got in. Someone added an account to your Domain Admins group in Windows Directory? You better be watching that. Verify that you’ll see what you want to see. Be creative, and be informed about the forensics artifacts left behind in the logs that you can and should alert on in your SIEM.