Category Archives: Ask the Security Experts

Brent’s Interview About His Most Recent Book

Posted on by
Reply

 

Introduction

In today’s digital age, the importance of cyber-security cannot be overstated. With threats evolving at an unprecedented rate, organizations need to be proactive in their approach to safeguarding their assets. “We Need To Talk: 52 Weeks To Better Cyber-Security” by L. Brent Huston offers a comprehensive guide to navigating the complex world of cyber-security. We sat down with the author to delve deeper into the inspiration, content, and significance of this book.

Interview

Q1: What inspired you to write “We Need To Talk: 52 Weeks To Better Cyber-Security”?

A1: As a virtual CISO and 30+ year security practitioner, I know how important it is to keep the security team engaged with one another, encourage open discussions, and do continual learning. I wrote the book to give security teams a good basis for these discussions every week for a year. Covering the basics and letting the team discuss sticking points and areas for improvement has led my clients to identify some interesting trends and rapidly mature their security programs. I think, literally, “We Need To Talk”. We need it as practitioners, individuals, teams, and organizations. This is a stressful, detail-oriented, rapid-change business, and talking helps nearly everyone involved.

Q2: Why did you feel it was essential to provide such a comprehensive view of cyber-security?

A2: So much of what we do is complex and touches multiple areas of our organization that we must bring the basics to each. I picked the topics for discussion in the book to address the high-level, technical, and procedural controls that almost every organization needs. I threw in some of the more tenacious topics I’ve encountered in my career and a few curve balls that have bitten us over the years. Information security and risk management are broad-spectrum careers, and we need a broad spectrum of topics to help security teams be successful.

Q3: Can you elaborate on how the structure of the book facilitates this year-long journey?

A3: This is a great question. The book idealizes a weekly security team meeting where the team discusses one of the topics and why it is relevant and then works through a series of questions to help them hone and refine their security program. The book includes a topic for each week, appropriate background information about that topic, and a set of questions for discussion by the team. As I piloted the book with my clients, it became clear that these were ultra-powerful discussions and led to some amazing insights. I knew then that I had to write and put the book out there to benefit security teams and practitioners.

Q4: How did leveraging AI tools shape the content and structure of the book?

A4: I used several AI tools to help generate the content of the book. It was written programmatically, in that I wrote some programming to leverage an AI backend to generate the questions and background information for each topic. I then adjusted the code and moderated the output until I got the book I wanted. It took a while, but it was fantastic when completed. I wanted to experiment with writing with AI tools, and since I knew the book I wanted to create had a specific format and content, it seemed like a good experiment. Ultimately, I learned much about working with AI and using Grammarly for editing and self-publishing. I have been absolutely thrilled with the response to the book and how the experiment turned out. In fact, it gave birth to another project that I am just beginning and will pave the way for some exciting new breakthroughs in how to work with AI tools in the coming years.

Q5: What is the one core message or lesson from your book that you’d like security teams to take away?

A5: The one takeaway I would have them consider is that discussion among the security team can really help a lot of the team members and the organization at large. We need to talk more about the work we do, both inside our teams and to the other teams we work with across the enterprise. The more we discuss, the more likely we can support each other and find the best solutions to our common problems and issues. Implementing the strategies, tactics, and insights we discover along the way might just be the change we need to make information security more effective, easier to manage, and even more fun!

Summary

L. Brent Huston’s “We Need To Talk: 52 Weeks To Better Cyber-Security” is more than just a book; it’s a roadmap for security teams to navigate the intricate maze of cyber-security. Through structured discussions, the book aims to foster collaboration, understanding, and growth among security professionals. With the unique blend of AI-generated content and Huston’s vast experience, this book promises to be an invaluable resource for those in the field.

 

* Just to let you know, we used some AI tools to gather the information for this article, and we polished it up with Grammarly to make sure it reads just right!

 

High-Level FAQ for Incident Response

Posted on by
Reply

  1. Q: What is an incident response process in information security?

A: The incident response process in information security is a systematic approach to identifying, containing, analyzing, and resolving security incidents that may compromise the confidentiality, integrity, or availability of an organization’s information systems and data. It involves a set of predefined policies, procedures, and tools designed to minimize the impact of security incidents and facilitate a swift recovery.

  1. Q: Why is the incident response process necessary?

A: The incident response process is crucial for organizations because it helps to minimize the damage caused by security incidents, protect sensitive data, maintain business continuity, and comply with regulatory requirements. A well-defined incident response process can also help organizations learn from security incidents and improve their overall security posture.

  1. Q: What are the critical phases of an incident response process?

A: The incident response process typically includes six key phases:

  • i. Preparation: Developing and maintaining an incident response plan, training staff, and setting up necessary tools and resources.
  • ii. Detection and Analysis: Identifying potential security incidents through monitoring, reporting, and analyzing security events.
  • iii. Containment: Limiting the spread and impact of an identified security incident by isolating affected systems or networks.
  • iv. Eradication: Removing the cause of the security incident, such as malware or unauthorized access, and restoring affected systems to a secure state.
  • v. Recovery: Restoring affected systems and networks to regular operation and verifying their security.
  • vi. Post-Incident Activity: Reviewing the incident response process, identifying lessons learned, and implementing improvements to prevent future incidents.

  1. Q: Who should be involved in the incident response process?

A: An effective incident response process involves a cross-functional team, typically called the Incident Response Team (IRT), which may include members from IT, information security, legal, human resources, public relations, and management. External stakeholders, such as law enforcement, third-party vendors, or cyber insurance providers, may also be involved, depending on the nature and severity of the incident.

  1. Q: How can organizations prepare for incident response?

A: Organizations can prepare for incident response by:

  • Developing a comprehensive incident response plan that outlines roles, responsibilities, and procedures for each process phase.
  • Regularly updating and testing the incident response plan to ensure its effectiveness and relevance.
  • Training employees on their roles and responsibilities during an incident, including reporting procedures and essential security awareness.
  • Establishing a well-equipped IRT with clear communication channels and access to necessary resources.
  • Implementing continuous monitoring and detection tools to identify potential security incidents early.

  1. Q: How can organizations improve their incident response process?

A: Organizations can improve their incident response process by:

  • Regularly reviewing and updating the incident response plan to reflect changes in the organization’s infrastructure, personnel, and threat landscape.
  • Conducting periodic tests and simulations, such as tabletop exercises or red team exercises, to evaluate the plan’s effectiveness and identify improvement areas.
  • Implement a continuous improvement cycle incorporating lessons learned from past incidents and industry best practices.
  • Investing in advanced detection and monitoring tools to enhance the organization’s ability to identify and respond to security incidents.
  • Providing ongoing training and support to the IRT and other stakeholders to ensure they remain up-to-date with the latest threats and best practices.

 

*This article was written with the help of AI tools and Grammarly.

SSL Certificate High-Level Best Practices

Posted on by
Reply

SSL certificates are an essential part of online security. They protect websites against hackers who try to steal information such as credit card numbers and passwords. In addition, they ensure that customers trust the site and its content.

Almost 50% of the top one million websites use HTTPS by default (they redirect inquiries of HTTP pages to URLs with HTTPS). (comodosslstore.com)As such, even pages that don’t deal with confidential data are being deployed using SSL. The underlying certificates to power the encryption are available from a variety of commercial providers, and even the pro-bono resource https://letsencrypt.org. No matter where you get your certificate from, here are a few resources for high-level best practices.

Trust Your Certificate Provider

Since certificates provide the basis for the cryptography for your site, their source is important. You can find a trustworthy list of providers for certificates here. https://www.techradar.com/news/best-ssl-certificate-provider. Beware of commercial providers not found on this list, as some of them may be sketchy at best, or dangerous at worst. Remember, the Let’s Encrypt project above is also highly trusted, even though they are not a commercial firm.

Manage Versions and Algorithms

Make sure you disable SSL and TLS 1.0 on the server. That version has known vulnerabilities. If possible, and there are no impacts on your users, consider removing 1.1 and 1.2 as well. 1.3 fixes a lot of the known issues with the protocol and supports only the known secure algorithms.

In cryptography, cipher suites play an important part in securing connections by enabling encryption at different levels. You shouldn’t be using an old version of a cryptographic protocol if there’s a newer one available; otherwise, you may put your site’s security at risk. Using secure cipher suites that support 128-bit (or more) encryption is crucial for securing sensitive client communications.

Diffie Hellman Key Exchange has been shown to be vulnerable when used for weaker keys; however, there is no known attack against stronger keys such as 2048-bits. Make sure you use the strongest settings possible for your server.

Manage and Maintain Certificate Expiration

As of Sept. 1, 2020, Apple’s Safari browser will no longer trust certificates with validity periods longer than 398 days, and other browsers are likely to follow suit. Reducing validity periods reduces the time period in which compromised or bogus certificates can be exploited. As such, any certificates using retired encryption algorithms or protocols will need to be replaced sooner. (searchsecurity.techtarget.com)

Maintain a spreadsheet or database of your certificate expiration dates for each relevant site. Make sure to check it frequently for expiring certificates to avoid user issues and browser error messages. Even better is to use an application or certificate management platform that alerts you in plenty of time to upcoming certificate expirations – thus, you can plan accordingly. Best of all, if possible, embrace tools and frameworks for automating certificate management and rotation – that makes sure that you are less likely to have expiration issues. Most popular web frameworks now have tools and plugins available to perform this for you.

Protect Your Certificates and Private Keys

Remember that your certificate is not only a basis for cryptography, but is also a source of identification and reputation. As such, you need to make sure that all certificates are stored properly, securely and in trusted locations. Make sure that web users can’t access the private certificate files, and that you have adequate back up and restore processes in place.

Make sure that you also protect the private keys used in certificate generation. Generate them offline, if possible, protect them with strong passwords and store them in a secure location. Generate a new private key for each certificate and each renewal cycle.

Revoke your certificate or keys as quickly as possible if you believe they have been compromised.

Following these best practices will go a long way to making your SSL certificate processes safer and more effective. Doing so protects your users, your reputation and your web sites. Make sure you check back with your certificate provider often, and follow any additional practices they suggest.

 

 

 

 

A vCISO Interview With Dave Rose

Posted on by
Reply

I had the pleasure to interview, Dave Rose, who does a lot of our virtual CISO engagements at MSI. I think you might enjoy some of his insights.

Q) In a few sentences, introduce yourself and describe your background that makes you a valuable virtual CISO. What are the keys to your success?

A) So my name is Dave Rose and I have been a CTO and in Technology for 25+ years. I started working daily with Risk as an Internal IT Auditor with the State of Ohio and expanded exponentially my knowledge and skills with JP Morgan Chase where I had day to day Risk responsibility for their Branch, ATM, Branch Innovation, Enterprise and Chase wealth Management applications. (548 to be exact!) What makes me a valuable CISO? In technology I have been audited by the best of them, SEC OCC,FINRA,Internal Audit, and been responsible for PCI and Basil compliance. I have had to review, implement and modify controls from NIST, ISO,SOX, GLBA, OWASP and CIS. In the financial industry I have worked with Agribusiness, Commercial Real Estate, Retail Banking, Investment Banking, Mutual Funds, Wealth Management, Credit Unions and 401K plans. As an IT/Operations manager/leader I have been responsible for Network Management, Finance, HR, Contract and Vendor Management, Help Desk, Development staff, Investment Operations, Sales, Cyber Engineers and Project Management, which I started my career performing. 

With the diversity that I listed above, there is a pretty good chance my past experience can help you to solve your current problems, now. A modicum of common sense, perseverance and a passion to do what right for the business while being responsible to the controls that make you successful has made me successful. 

Q) Speaking as a virtual CISO, what are some of the toughest challenges that your clients are facing this year?

A) I think that one of the biggest challenge that our clients are facing this year is Technology Deficit. I dont think this is anything new but with the deprecation of Win 7 and the threat of Ransomware, holding onto old technology with critical vulnerabilities is no longer an option. Whether is is hardware, software or code updates, companies cannot continue to mortgage technology debt to the future. Hate to be cliche but the time is now. 

Q) If you met with a board and they wanted to know what percentage of revenue they should be spending on information security, how would you answer that question?

A) I hate this question because it really does not have a good answer. A board asked me once “How much money would it cost me to get to a 3.5 on the NIST scale?” Money is only one facet of solving risk, there is culture, leadership, technology and business vision. Know and set the roadmap for all of those items for the next 5 years and your dollar investment will come naturally. So 6-7% (Rolls eyes)

Q) In terms of the NIST model, can you walk us through how you would prioritize the domains? If you came into a new organization, where would you start in the NIST model to bring the most value and what would the first 100 days look like?

A) There are two areas of the NIST model I would focus on, identify and protect. I would take a good hard look at access administration and all the components that make that up. Next I would look at log analysis and aggregation. I would spend the first hundred days doing a Risk Assessment of the entire environment but would also create a roadmap based on evaluation of current state for both Access Administration and Log Governance. Based on your results and determination of Risk and Reward (80/20 rule) map out the next 1-3 years. 

Q) If folks wanted to learn more about your insights or discuss having you work with them as a virtual CISO or security oversight manager, how can they reach you?

A) If you would like to talk further about these question, insights or would like to hear more about the MSI vCISO service, you can reach me at 614 372–6769, twitter @dmr0120 or e-mail at drose@microsolved.com!

Prepping for Incident Response

Posted on by

Prepping? Who wants to prep for incident response?

This particular bit of writing came from a question that I was asked during a speaking engagement recently – paraphrased a bit.

How can a client help the incident team when they’re investigating an incident, or even suspicious activity? 

So, I circulated this to the team, and we tossed around some ideas.

Continue reading →

Ask The Experts: Why Do Security Testing of Internal Computer Networks?

Posted on by
Reply

Most organizations have realized the need to have vulnerability assessments of their internet-facing (external) computer networks performed periodically. Maybe they are alarmed by all the data compromises they hear about on the news or perhaps they are subject to regulatory guidance and are required to have vulnerability assessments done. But many organizations draw the line there and never have the security of their internal networks tested. This is a mistake! At least it’s a mistake if your goal is actually to protect your computer systems and the private information they store and process.

It is true that the most attacks against information systems come from external attackers, but that does not mean the internal threat is negligible. About one sixth of data compromises are due to employees and privileged insiders such as service providers and contractors. But there are many other reasons for testing the security of your internal networks besides the internal threat. For one thing, once cyber-criminals find a hole in your external defenses they are suddenly “insiders” too. And if your internal systems are not configured correctly, hardened and monitored, it becomes trivial for these attackers to own your systems and compromise all the private information you have.

The type of testing that gives you the most bang for the buck is internal vulnerability assessment. Doing this type of testing regularly has many benefits. One benefit that people usually don’t associate with internal vulnerability assessment is that it can be used to make maps and inventories of the network. These are essentials of information security. After all, if you don’t know what you have on your network and where it is, how can you protect it? Another benefit is that it allows you to view your internal network with perspective. In other words, it lets you see it the way an attacker would. It will reveal:

  • Access control issues such as default and blank passwords mistakenly left on the network during administration, open files shares or anonymous FTP sites that may contain private data or user accounts that are suspicious or inappropriate.
  • Systems that are missing security patches or that are running out of date software or operating systems that are no longer supported by the vendors.
  • Systems that have been misconfigured or that reveal too much information to unauthorized users.
  • Ports that are inappropriately left open or dangerous services such as Telnet or Terminal Services present on the network.
  • Poor network architecture that fails to properly segment and enclave information assets so that only those with a business need can access them.
  • How well third party systems present on your network are patched, updated and secured.

Also, from a business perspective, performing regular internal vulnerability assessments shows your customers that you are serious about information security; a factor that could influence them to choose your organization over others.

In addition to vulnerability testing, it is also more than just desirable to have penetration testing of the internal network performed occasionally. While vulnerability assessment shows you what flaws are available for attackers to exploit (the width of your security exposure), penetration testing shows you what attackers can actually do with those flaws to compromise your systems and data (the depth of your security exposure). Internal penetration testing can:

  • Reveal how attackers can exploit combinations of seemingly low risk vulnerabilities to compromise whole systems or networks (cascading failures).
  • Show you if the custom software applications you are using are safe from compromise.
  • Show you not only what is bad about your network security measures, but what is working well (this can really save you money and effort by helping you chose only the most effective security controls).

One other type of penetration testing that is well worth the time and expense is social engineering testing. As network perimeters become increasingly secure, social engineering techniques such as Phishing emails or bogus phone calls are being used more and more by attackers to gain a foothold on the internal network. We at MSI are very aware of just how often these techniques work. How well do you think your employees would resist such attacks?

Thanks to John Davis for this post.

Ask The Experts: Favorite HoneyPoint Component

Posted on by
Reply

This time around, we got a question from a client where HoneyPoint was being demoed for the experts.

Q: “What is your favorite component of HoneyPoint and why? How have you used it to catch the bad guys?”

Jim Klun started off with:

My favorite component is the simplest: HoneyPoint Agent. 

It’s ease of deployment and the simple fact that all alerts from an agent are of note – someone really did touch an internal service on a box where no such service legitimately exists – makes it attractive. 
No one will argue with you about meaning. 

I have recently seen it detect a new MSSQL worm (TCP 1433) within a large enterprise – information obtained from my own laptop. The Agent I had deployed on the laptop had a 1433 listener. It captured the payload from an attacking desktop box located in an office in another US state. 

The HoneyPoint Agent info was relayed to a corporate team that managed a global IPS. They confirmed the event and immediately updated their IPS that was – ideally – protecting several hundred thousand internal machines from attack. 

Honeypoint Agent: It’s simple, it works.

Adam Hostetler added his view:

I’m a simple, no frills guy, so I just like the regular old TCP listener component built into Agent. We have stood these up on many engagements and onsite visits and picked up unexpected traffic. Sometimes malware, sometimes a misconfiguration, or sometimes something innocuous (inventory management). I also find it useful for research by exposing it to the Internet.

John Davis closed with a different view:

My favorite HoneyPoint is Wasp. Watching how skilled attackers actually compromise whole networks by initially compromising one user machine gives me the shivers! Especially since most networks we see aren’t properly enclaved and monitored. If I were a CISO, knowing what is on my network at all times would be of primary importance; including what is going on on the client side! Wasp gets you that visibility and without all the traditional overhead and complexity of other end-point monitoring and white listing tools.

Have a question about HoneyPoint? Want to talk about your favorite component or use case scenario? Hit us on Twitter (@lbhuston or @microsolved). We can’t wait to hear from you. Feel free to send us your question for the experts. Readers whose questions we pick for the blog get a little surprise for their contribution. As always, thanks for reading and stay safe out there! 

Ask The Experts: New Device Check Lists

Posted on by
2

This time around on Ask The Experts, we have a question from a reader and it got some great responses from the team:

 

Q: “I need a quick 10 item or less checklist that I can apply to new devices when my company wants to put them on our network. What kinds of things should I do before they get deployed and are in use around the company?”

 

Bill Hagestad started us off with:

The Top 10 checklist items a CISO/or equivalent authority should effectively manage before installing, configuring and managing new devices on a network includes the following;

 

1)Organize your staff and prepare them for the overall task of documenting and diagramming your network infrastructure – give them your commander’s network management intent;

2)Create a physical and logical network map – encourage feedback from your team regarding placement of new hardware and software;

3)Use industry standards for your network including physical and logical security, take a good look at NIST Special Publication SP 800-XX Series;

4)Make certain that you and your team are aware of the requisite compliance standards for your business and industry, it will help to ensure you are within legal guidelines before installing new devices or perhaps you may discover the hardware or software you are considering isn’t necessary after all;

5)Ensure that after you have created the necessary network maps for your infrastructure in Step 2) above, conduct a through inventory of all infrastructure which is both critical and important to your business, then document this baseline;

6)Create a hardware/software configuration change procedure; or if you already have his inlace, have your team review it for accuracy; make certain everyone on the team knows to document all changes/moves/additions on the network;

7)Focus not only on the correlation of newly implemented devices on the internal networks but also look at the dependencies and effects on external infrastructure such as voice/data networks – nothing worse than making an internal change to your network and having your Internet go down unnecessarily;

8)Ensure that new network devices being considered integrate gracefully into your existing logging and alerting mechanisms; no need to install something new only to have to recreate the proverbial wheel in order to monitor it;

9)Consider the second & third order effects of newly installed devices on the infrastructure and their potential impact on remote workers and mobile devices used on the network;

10)Install HoneyPoint Security Server (HPSS) to agentlessly & seamlessly monitor external and potential internal threats to your newly configured network….

 

Of course a very authoritative guide is published by the national Security Agency called appropriately “Manageable Network Plan” and available for download @:

 

http://www.nsa.gov/ia/_files/vtechrep/ManageableNetworkPlan.pdf


Jim Klun added:

1. Make sure the device is necessary and not just a whim on the part of management.   Explain that each new device increases risk. 

2. If the device’s function can be performed by an existing internal service, use that service instead. 

3. Inventory new devices by name, IP addresses, function and – most importantly – owners.  There should be a device owner and a business owner who can verify continued need for the device.  Email those owners regularly,   querying them about continued need. Make sure that these folks have an acknowledged role to support the application running on the devices and are accountable for its security. 

4. Research the device and the application(s) its support.  Have no black boxes in your datacenter.  Include an abstract of this in the inventory. 

5. Make sure a maintenance program is in place – hold the app and device owner accountable. 

6. Do a security audit of the device wehn fully configured. Hit it with vulnerability scanners and make sure that this happens at least quarterly. 

7. Make sure monitoring is in place and make very sure all support staff are aware of the device and any alerts it may generate. Do not blind-side the operations staff. 

8. If the device can log its activities ( system and application ) to a central log repository, ensure that happens as part of deployment. 

9. Make sure the device is properly placed in your network architecture. Internet-exposed systems should be isolated in an Internet DMZ.  Systems holding sensitive data should similarly be isolated. 

10. Restrict access to the device as narrowly as possible. 

 

Finally.. if you can, for every device in your environment, log its network traffic and create a summary of what is “normal” for that device.  

Your first indication of a compromise is often a change in the way a system “talks”. 

 

Adam Hostetler chimed in with: 

Will vary a lot depending on device, but here are some suggestions

 

1. Ensure any default values are changed. Passwords, SNMP strings, wireless settings etc.

2. Disable any unnecessary services

3. Ensure it’s running the latest firmware/OS/software

4. Add the device to your inventory/map, catalog MAC address, owner/admin, etc.

5. Perform a small risk assessment on the device. What kind of risk does it introduce to your environment? Is it worth it?

6. Test and update the device in a separate dev segment, if you have one.

7. Make sure the device fits in with corporate usage policies

8. Perform a vulnerability assessment against the device. 

9. Search the internet for any known issues, vulnerabilities or exploits that might effect the device.

  1. Configure the device to send logs to your logging server or SEIM, if you have one.

 

And John Davis got the last word by adding: 

From a risk management perspective, the most important thing a CISO needs to ensure is in place before new devices are implemented on the network is a formal, documented Systems Development Life Cycle or Change Management program. Having such a program in place means that all changes to the system are planned and documented, that security requirements and risk have been assessed before devices have purchased and installed, that system configuration and maintenance issues have been addressed, that the new devices are included in business continuity planning, that proper testing of devices (before and after implementation on the network) is undertaken and more. If a good SDLC/Change Management program is not in place, CISOs should ensure that development and implementation of the program is given a high priority among the tasks they wish to accomplish.

 

Whew, that was a great question and there is some amazing advice here from the experts! Thanks for reading, and until next time, stay safe out there! 

 

Got a question for the experts? Give us a shout on Twitter (@microsolved or @lbhuston) and we’ll base a column on your questions!

Ask The Experts: Too Much Data

Posted on by
2

Q: “I have massive amounts of log files I have to dig through every day. I have tried a full blown SEIM, but can’t get it to work right or my management to support it with budget. Right now I have Windows logs, firewall logs and AV logs going to a syslog server. That gives me a huge set of text files every day. How can I make sense of all that text? What tools and processes do you suggest? What should I be looking for? HELP!!!!”

 

Adam Hostetler answered with:

 

I would say give OSSEC a try. It’s a free log analyzer/SEIM. It doesn’t

have a GUI with100 different dashboards and graphs, it’s all cli and

e-mail based (though there is a simple web interface for it also). It is

easy to write rules for, and it has default rules for many things,

except for your AV. You can write simple rules for that, especially if

you are just looking for items AV caught. It does take some tuning, as

with all analysis tools, but isn’t difficult after learning how OSSEC

works. If you want to step it up a bit, you can feed OSSEC alerts into

Splunk where you can trend alerts, or create other rules and reports in it.

 

Bill Hagestad added:

 

First things first – don’t be or feel overwhelmed – log files are what they are much disparate data from a variety of resources that need reviewing sooner rather than later.

 

Rather than looking at another new set to tools or the latest software gizmo the trade rags might suggest based on the flair of the month, try a much different and more effective approach to the potential threat surface to your network and enterprise information network.

 

First take a look at what resources need to be protected in order of importance to your business. Once you have prioritized these assets then begin to  determine what is the minimum level of acceptable risk you can assign to each resource you have just prioritized.

 

Next, make two columns on a either a piece of paper or a white board. In one column list your resources in order of protection requirements, i.e.; servers with customer data, servers with intellectual property, so and so forth. In a column to the right of the first assets list plug in your varying assigned levels of risk. Soon you will see what areas/assets within your organization/enterprise you should pay the most attention to in terms of threat mitigation.

 

After you have taken the steps to determine your own self- assessment of risk contact MicroSolved for both a vulnerability assessment and penetration test to provide additional objective perspective on threats to your IT infrastructure and commercial enterprise. 

 

Finally, Jim Klun weighed in with: 

 

You are way ahead of the game by just having a central log repository.  You can go to one server and look back in time to the point where you expect a security incident.

 

And what you have – Windows logs, firewall logs, and AV – is fantastic.  Make sure all your apps are logging as well ( logon success, logon failure).

Too often I have seen apps attacked and all I had in syslog was OS events that showed nothing.

 

Adam’s suggestion, OSSEC, is the way to go to keep cost down… but don’t just install and hope for the best.

You will have to tweak the OSSEC rules and come up with what works.

 

Here’s the rub: there is no substitute for knowing your logs – in their raw format, not pre-digested by a commercial SIEM or OSSEC.

 

That can seem overwhelming. And to that, some Unix commands and regular expressions are your friend.

 

So:

 

zcat auth.log | grep ssh | egrep -i ‘failed|accepted’

 

produces:

 

Jul  4 16:32:16 dmz-server01 sshd[8786]: Failed password for user02 from 192.168.105.51 port 38143 ssh2

Jul  4 16:33:53 dmz-server01 sshd[8786]: Accepted password for user01 from 192.168.105.38 port 38143 ssh2

Jul  4 16:36:05 dmz-server01 sshd[9010]: Accepted password for user01 from 192.168.105.38 port 38315 ssh2

Jul  5 01:04:00 dmz-server01 sshd[9308]: Accepted password for user01 from 192.168.105.38 port 60351 ssh2

Jul  5 08:21:58 dmz-server01 sshd[9802]: Accepted password for user01 from 192.168.105.38 port 51436 ssh2

Jul  6 10:21:52 dmz-server01 sshd[21912]: Accepted password for user01 from 192.168.105.38 port 36486 ssh2

Jul  6 13:43:10 dmz-server01 sshd[31701]: Accepted password for user01 from 192.168.105.30 port 34703 ssh2

Jun 26 11:21:02 dmz-server01 sshd[31950]: Accepted password for user01 from 192.168.105.70 port 37209 ssh2

 

 

Instead of miles of gibberish the log gets reduced to passed/fail authentication attempts.

 

You can spend an hour with each log source ( firewall, AV, etc) and quickly pare them down to whats interesting.

 

Then make SURE your OSSEC  rules cover what you want to see.

If that does not work – cron a script to parse the logs of interest using your regular expression expertise and have an email sent to you when something goes awry.

 

Revisist the logs manually periodically – they will change. New stuff will happen.  Only a human can catch that.

 

Take a look at:

http://www.securitywarriorconsulting.com/logtools/

 

The site lists a number of tools that may be useful

 

John Davis added:

 

You voice one of the biggest problems we see in information security programs: monitoring! People tell us that they don’t have the proper tools and, especially, they don’t have the manpower to perform effective logging and monitoring. And what they are saying is true, but unfortunately doesn’t let them out from having to do it. If you have peoples financial data, health data (HIPAA) or credit card information (PCI) you are bound by regulation or mandate to properly monitor your environment – and that means management processes, equipment, vulnerabilities and software as well as logs and tool outputs. The basic problem here is that most organizations don’t have any dedicated information security personnel at all, or the team they have isn’t adequate for the work load. Money is tight and employees are expensive so it is very difficult for senior management to justify the expenditure – paying a third party to monitor firewall logs is cheaper. But for real security there is no substitute for actual humans in the security loop – they simply cannot be replaced by technology. Unfortunately, I feel the only answer to your problem is for government and industry to realize this truth and mandate dedicated security personnel in organizations that process protected data.

 

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

Ask The Experts: Daily Tasks

Posted on by
3

This time around, we get a great question from a reader:

Q: “I’m a one man infosec team at a small financial company, and as such, I stay overtasked. Can you give me a few examples of some key tasks I should make sure I am doing daily/weekly/monthly to make sure I am hitting them all and to help me better structure my schedule?”

Bill Hagestad answered with:

Daily Tasks: 

– Keep self and staff educated about latest cyber threats to your business – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Review what Federal Law Enforcement considers top cyber threats are base on current cases:
– Compromise of account holder credentials leading to legitimate account compromise;
-Via  phasing attack vectors; unauthorized ACH transfers; 
– Compromise of Third Party Payment Processors;
 
Source: FBI Threat To Financial Sector
 
-Insider attacks – perhaps the largest threat to any commercial enterprise – especially given the recent NSA dilemma via a US contractor
 
– Have staff follow all account verification standing operating procedures – covering all types of customer interaction, including but not limited to; phone, Internet, and in-person account interactions;
– Information Security/Assurance infrastructure configuration changes should be reviewed daily and approved/counter-approved internally to eliminate potential administrative abuses;
– Hold weekly Information Security/Assurance infrastructure team meetings – invite MicroSolved to participate as a credible resource for staff to ask questions of and make sound recommendations.
 
Weekly Tasks:
 
– Stay ahead of international financial sector threat intelligence – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Ensure account access lists are secure and validated both for external customers (most importantly) and also internal employee need to access/right to access customer account information;
  
Monthly Tasks:
 
– Participate in professional cyber/information assurance mailing lists – if not sure who or what these are contact MSI Cyber Threat Intelligence;
– Be certain to review the US Government Hearing Notes: Cybersecurity: Threats to the Financial Sector downloadable @ http://www.gpo.gov/fdsys/pkg/CHRG-112hhrg72601/pdf/CHRG-112hhrg72601.pdf
– Review or create a cyber threat identification strategy involving key staff and MicroSolved – install HoneyPoint Security Server to capture knowledge about who truly is probing your network, eliminate the proverbial network noise and focus on specific threat actors – e.g.; Russian Cyber Crimianls, Chinese entities using government cyber espionage tools for crime purposes
 
Adam Hostetler added:
It’s hard to answer exactly what you should be doing on a timely basis
without reviewing your current requirements, tools, processes, and
infrastructure. However, If you go to www.microsolved.com and look at
our 80/20 white paper, you can use that as a guideline to give you some
ideas to help build out your security program.

Examples of some things you could/should be doing.

Daily:
Log reviews. Not necessary for all logs, but if you have
IDS/IPS/Honeypots etc, they should be reviewed and investigated if needed
Spend a bit of time following up on the latest security news/threats.
That includes things like new vulnerabilities or exploits, and then
following up if it would affect you.

Weekly:
Check and verify backups and processes

Monthly:
Update software/OS patches.

 
Finally, Jim Klun weighed in with: 
1. Make sure your subscribed to security news-feeds/alerting services that apply to your environment. Review those daily.

2. Make sure you are reviewing your logs daily.  You should know every day about successful and unsuccessful logins. You should also be paying attention to your firewall logs for inbound activity and outbound activity.

3 If you have a local help desk, talk to them at least monthly. They are often in a position to see things that are in fact security problems.

4. Automate your patching program if that is not true already, then review patch reports monthly.

5. If you have Internet exposures, check them monthly. Make absolutely sure at the end of each month you are absolutely sure of what services your organization offers to the Internet – and why.

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston).