Author Archives: Brent Huston

About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

EDI – The Often Overlooked Critical Process in Utilities

Posted on by
Reply

EDI (Electronic Data Interchange) is an often forgotten underpinning of many utility companies, even though many of its functions are likely to be critical to the operation. In many states, EDI is a mandated operation for commercial bill pay and meter reading data exchange with third party services. In fact, between the Gas Industry (GISB) and North American Energy (NAESB) Standards Boards, a substantial set of requirements exist for industry use of EDI.

Data

While EDI exists as a specific set of functions for exchanging digital data, it is often managed through third party applications and networks. These operations carry several different threat models, from disruption of service and outages that impact the data availability, to tampering and compromise of the data in transit. As such, it is essential that utilities have performed business function and application specific risk assessment on EDI implementations.

Additionally, many of our clients have performed EDI-focused penetration testing and technical application assessments of their EDI translators and network interconnects. Some clients still utilize a Value Added Network (VAN) or other service provider for EDI transmissions, and MSI can work with your VAN to review their security program and the configuration of your interconnections to ensure maximum security and regulatory compliance.

Lastly, our team has been very successful doing tabletop incident response and disaster recovery/business continuity exercises involving modeling EDI outages, failures and data corruption. Impacts identified in these role playing exercises have ranged from critical outages to loss of revenue.

If you’d like to learn more about our EDI services and capabilities, give us a call at 614-351-1237 or drop us a line at info@microsolved.com. We’d love to talk with you about our nearly 30 years of experience in EDI, information security and critical infrastructure.

 

 

 

Announcing the Launch of the SecureDrive Alliance

Posted on by
Reply

LMS Consulting and MicroSolved are proud to announce the launch of the SecureDrive Alliance. This team effort is specifically focused on the needs, regulatory requirements and threats facing automotive dealerships today.

SecureDrive Alliance

The alliance will be providing the following focused services to dealerships across the US:

  • Risk assessments
  • Vulnerability assessment and penetration testing
  • Application security
  • Phishing simulations
  • Risk management training

To learn more about the SecureDrive Alliance, the leaders of both companies have put together a quick MP3 discussing the reasons behind the launch and the capabilities that the alliance brings to bear. You can listen to the 9 minute MP3 here.

To put the team to work on securing your dealership, give a call to Justin LeBrun, or drop him an email.

What Do I Need To Know About Source Code Leaks?

Posted on by
Reply

Leaked source code happens a lot more frequently than most of our clients care to admit. Often, many clients are surprised when they begin using ClawBack™ to hunt for and take down leaked source code, configuration data and credentials. Most customers tell us they expect not to find anything at all, and many times they are simply astounded when their initial monitoring reports find critical examples of leaked source code out in the wild.

At MSI, however, we’re not surprised when these things happen. After all, that’s why we built ClawBack to begin with. We were tired of working incident after incident and breach after breach that resulted from these leaks. We knew we had to create a better way for our clients to stay on top of leaked source code, configurations and credentials.

Why Source Code Matters

When we talk about leaked source code with clients, most are worried about the loss of intellectual property. That’s a fair risk assessment, and the impacts can be long standing. Take for example, the leak of RSA source code in 2011, that underlined their flagship SecureID product, and was perpetrated via an external hacking team. The SecureID token is used to add a layer of security into the login process for corporate networks and applications. This meant that the very heart of security in an organization that used these tokens was at risk. In the end, RSA had to replace all of the SecureID devices in circulation. The cost to RSA hit $66 million in terms of replacing the physical tokens. However, other intangible costs such as reputation have a longer and less quantifiable reach. (stop-source-code-theft.com)

But, while we know that intellectual property loss can be an issue, we’ve seen many breaches stem from leaked code. In fact, an estimated 75% of security breaches are enabled when developers code secret access keys and passwords into source code. (assembla.com) We’ve seen it time and time again, across verticals from manufacturing to healthcare and from banking and finance to critical infrastructure. Source code leaks are often a powerful tool of the attacker.

How Source Code Leaks

External hackers are certainly a significant threat to source code security, as seen in the RSA leak above. But hackers are responsible for a far smaller percentage of leaks than you would expect. Instead, the majority of source code leaks come from human mistakes. 

According to Wikipedia, source code leaks are usually caused by misconfiguration of software like CVS or FTP which allow people to get source files through exploits, software bugs , or employees that have access to the sources or part of them revealing the code. (en.wikipedia.org) We agree with this stance, since the majority of leaks ClawBack finds for clients end up getting traced back to misconfigurations of IDE plugins or developers not checking carefully which code repository they are committing their code to. 

Yet another common root cause of code leaks found by ClawBack has been developers sharing code they developed at different companies as a part of their resume and portfolio. While this is very common for freelancers, consultants and contractors, several significant leaks have also been traced back to the portfolios of full-time employees.

A good source code security awareness program and ongoing auditing of plugins, configurations and repositories are strong controls to reduce these risks. After all, as several firms have found out the hard way, even approved and well-known code repositories, that began as open source contributions or accepted projects for sharing with the public, can drift into leaking critical confidential data before you know it. That’s why keeping an eye on all repositories, even the ones fully approved to be public, is essential. If you need help with any of these controls, don’t worry, MicroSolved is here to help with any or all of them.

How Can ClawBack Help With Leaked Code?

ClawBack stands ever-vigilant, continually searching for and hunting down code that leaks from your organization. You configure monitoring terms, using MSI’s documented process, experience and guidance, and set ClawBack to work. Since it serves as an independent third party, it doesn’t rely on monitoring your network or workstations like traditional Data Leak Protection (DLP) products. In fact, almost all of our clients have extensive DLP instances, but still find leaked code. Traditional DLP often focuses on common PII/PHI data types, and even more concerning, the majority of the leaks our clients have found with ClawBack actually get traced back to origins outside of the company network and computing environment – a fact that renders traditional DLP powerless.

ClawBack monitors for your terms in the most common areas of the Internet where source code leaks occur. It searches thousands of code repositories, product support sites, question and answer forums and other nooks and crannies of the web where code samples and such are likely to end up. Once identified, ClawBack alerts you to the presence of your critical data and provides advice on “clawing back” that critical information with takedown requests and search engine cleanup.

Overall, ClawBack serves clients as a watchful eye for leaked source code. It can mean the difference between code being available for minutes versus years, and between a leak and a breach. If you’d like to learn more about ClawBack, give us a call today (614-351-1237) or drop us a line (info@microsolved.com). We’d love to tell you how ClawBack can work for you! 

Three Things I’ve Learned About Credit Union Risk Management

Posted on by
Reply

I have been working with Credit Unions for more than 20 years and have done a wide variety of information security and risk management work over that time. I’ve worked with technical teams, management and boards over the span of more than two decades. Here are three things I’ve learned about how CUs manage risk during that time. 

1) Most credit unions that I’ve worked with care just as much, if not more, about information security than most of the regional size banks they often compete with.

I’ve heard more than one CU leader tell me that they have to be better than the banks, because when a bank gets hacked – that bank makes the news and feels the impact. However, he said, when a credit union gets hacked – all credit unions suffer from the bad press. I am not sure the data supports his claim, but it’s an example of how CUs often focus on working together to solve big problems, and put a lot more attention to detail into it.

2) Many of the credit unions I have worked with look at information security and threat awareness as something that they can offer to their members (“customers, in bank speak”).

More than a few of the CUs have engaged so deeply with their customers on phishing and identify theft, that they include them in discussions about what products and services the CU buys. They do trials, include members in beta-tests and I’ve even seen them do onsite training for how to use new multi-factor authentication tools – even ones that weren’t in use at the CU – just to help make the members more secure and reduce the threat of password re-use across personal sites.

3) The board is often more involved in the risk management process at my CU clients than my banking clients.

The NCUA has taken a lot of steps to increase board member awareness about information security, and it often shows at credit unions. Several times a year, I am asked to present threat updates or review the information security program of a CU, specifically with a presentation to the board in mind. I am often engaged as a third party, to spend a couple of days looking at a security program and reporting to the board on it’s maturity and areas of potential improvement.

During these board sessions, it is not uncommon for the board questions to last more than an hour, after the presentation has completed. The point is, most CU boards that I have worked with are deeply engaged in thinking about risk management at the credit union.

For those of you interested in more about risk management at credit unions, here are some of the best sources, which I refer to often in my presentations:

  • Credit unions also face such internal risks as internal fraud, legal and regulatory noncompliance, data breaches, and injuries to staff and visitors. (boardeffect.com)

  • The bottom line: Figuring out the risk appetite will help guide credit unions to create realistic and measurable risk guidelines. (visibleequity.com)

  • We have helped Credit Unions develop risk appetite statements and risk frameworks and can work with your Credit Union to develop the documentation you require. (creditunionupdate.com)

If you’d like to learn more about MSI and our work with credit unions, just drop us a line (info@microsolved.com) or give us a call (614-351-1237) and we’d be happy to talk about how we might be able to help your credit union excel in IT risk management.

Pandemic Planning Webinar Materials

Posted on by
Reply

John Davis and David Rose held a pandemic planning webinar on the 17th of March.

Here are the materials from the event, in case you were not able to attend.

PDF of slide deck: https://media.microsolved.com/Pandemic.pdf

MP4 recording of event: https://media.microsolved.com/2020-03-17%2010.00%20Pandemic%20Planning%20Update.mp4

Event Description:

MicroSolved’s John Davis and Dave Rose will explore pandemic plan updates in the age of the COVID-19 outbreak. They will discuss lessons learned, from  building a basic plan to updating existing plans. They will share the latest advice from our consulting practice, from State, Local and Federal resources and point out a variety of resources that are now available to assist organizations.

We hope this help folks and of course, if we can be of any assistance, please let us know. We are all in this together, and MSI is here to help wherever and whenever we can. Stay safe out there! 

Pandemic Planning Update Webinar Scheduled

Posted on by
Reply

WorldShieldWe are proud to announce a pandemic planning update webinar scheduled for Tuesday, March 17th at 10am Eastern.

MicroSolved’s John Davis and Dave Rose will explore pandemic plan updates in the age of the COVID-19 outbreak. They will discuss lessons learned, from  building a basic plan to updating existing plans. They will share the latest advice from our consulting practice, from State, Local and Federal resources and point out a variety of resources that are now available to assist organizations.

Click here to register. Recordings will be made available after the event. 

We want everyone to benefit from pandemic planning. Please let us know if you have questions or need assistance.

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!

3 Threats We Are Modeling for Clients These Days

Posted on by
Reply

Just a quick post today to discuss three threat scenarios we are modeling frequently with clients these days. #ThreatModeling

1) Ransomeware or other malware infection sourced from managed service providers – this scenario is become a very common issue, so common that DHS and several other organizations have released advisories. Attacker campaigns against managed services providers have been identified and many have yielded some high value breaches. The most common threat is spear phishing into a MSP, with the attackers eventually gaining access to the capability to push software to the clients. They then push a command and control malware or a ransomware infection down the pipe. Often, it is quite some time before the source of the event is traced back to the MSP. The defenses here are somewhat limited, but the scenario definitely should be practiced at the tabletop level. Often, these MSPs have successfully passed a SOC audit, but have very little security maturity beyond the baselines.

2) Successful credential stuffing attacks against Office 365 implementations leading to wire/ACH/AP fraud – This is another very common scenario, not just for banks and credit unions, but a lot of small and mid-size organizations have fallen victim to it as well via account payable attacks. In the scenario, either a user is phished into giving up credentials, or a leaked set of credentials is leveraged to gain access to the Office 365 mail and chat system. The attackers then leverage this capability to perform their fraud, appearing to come from internal email accounts and chats. They often make use of stored forms and phish their way to other internal users in the approval chain to get the money to actually move. Once they have their cash, they often use these email accounts to spread malware and ransomware to other victims inside the organization or in business partners – continuing the chain over and over again. The defenses here are to MFA, limited access to the O365 environment to require VPN or other IP-specifc filtering, hardening the O365 environment and enabling many of the detection and prevention controls that are off by default. 

3) Voicemail hacking and dial-system fraud – I know, I know, it’s 2020… But, this remains an incredibly impactful attack, especially against key management employees or employees who traffic in highly confidential data. Often this is accessed and then either used for profit via trading (think M&A info) or as ransom/blackmail types of social engineering. Just like above, the attackers often hack one account and then use social engineering to get other users to follow instructions around fraud or change their voicemail password to a given number, etc. Larger corporations where social familiarity of employees and management is low are a common attack target. Dial system fraud for outbound long distance remains pretty common, especially over long weekends and holidays. Basically, the attackers hack an account and use call forwarding to send calls to a foreign number – then sell access to the hacked voicemail line, changing the destination number for each caller. Outbound dial tone is also highly regarded here and quite valuable on the underground markets. Often the fraud goes undetected for 60-90 days until the audit process kicks in, leaving the victim several thousand dollars in debt from the illicit activity. The defenses here are voicemail and phone system auditing, configuration reviews, hardening and lowering lockout thresholds on password attempts. 

We can help with all of these issues and defenses, but we love to help organizations with threat scenario generation, threat modeling and attack surface mapping. If you need some insights into outside the box attacks and fraud potential, give us a call. Our engagements in this space are informative, useful and affordable.

Thanks for reading, and until next time, stay safe out there! 

3 Lessons From 30 Years of Penetration Testing

Posted on by
Reply

I’ve been doing penetration tests for 30 years and here are 3 things that have stuck with me.

I’ve been doing penetration testing for around 3 decades now. I started doing security testing back when the majority of the world was dial-up access to systems. I’ve worked on thousands of devices, systems, network and applications – from the most sensitive systems in the world to some of the dumbest and most inane mobile apps (you know who you are…) that still have in-game purchases. 

Over that time, these three lessons have stayed with me. They may not be the biggest lessons I’ve learned, or the most impactful, but they are the ones that have stuck with me in my career the longest. 

Lesson 1: The small things make or break a penetration test. The devil loves to hide in the details.

Often people love to hear about the huge security issues. They thrill or gasp at the times when you find that breathtaking hole that causes the whole thing to collapse. But, for me, the vulnerabilities that I’m most proud of, looking back across my career are the more nuanced ones. The ones where I noticed something small and seemingly deeply detailed. You know the issues like this, you talk about them to the developer and they respond with “So what?” and then you show them that small mistake opens a window that allows you to causally step inside to steal their most critical data…

Time and time again, I’ve seen nuance vulnerabilities hidden in encoded strings or hex values. Bad assumptions disguised in application session management or poorly engineered work flows. I’ve seen developers and engineers make mistakes that are so deeply hidden in the protocol exchanges or packet stream that anyone just running automated tools would have missed it. Those are my favorites. So, my penetration testing friend, pay attention to the deep details. Lots of devils hide there, and a few of those can often lead to the promised land. Do the hard work. Test every attack surface and threat vector, even if the other surfaces resisted, sometimes you can find a subtle, almost hidden attack surface that no one else noticed and make use of it.

Lesson 2: A penetration test is usually judged by the report. Master report writing to become a better penetration tester. 

This is one of the hardest things for my mentees to grasp. You can geek out with other testers and security nerds about your latest uber stack smash or the elegant way you optimized the memory space of your exploit – but customers won’t care. Save yourself the heartbreak and disappointment, and save them the glazed eyes look that comes about when you present it to them. They ONLY CARE about the report.

The report has to be well written. It has to be clear. It has to be concise. It has to have make them understand what you did, what you found and what they need to do about it. The more pictures, screen shots, graphs and middle-school-level language, the better. They aren’t dumb, or ignorant, they just have other work to do and need the information they need to action against in the cleanest, clearest and fastest way possible. They don’t want to Google technical terms and they have no patience for jargon. So, say it clear and say it in the shortest way possible if you want to be the best penetration tester they’ve seen. 

That’s hard to swallow. I know. But, you can always jump on Twitter or Slack and tell us all about your L33T skillz and the newest SQL technique you just discovered. Even better, document it and share it with other testers so that we all get better.

Lesson 3: Penetration tests aren’t always useful. They can be harmful.

Lastly, penetration tests aren’t always a help. They can cause some damage, to weak infrastructures, or to careers. Breaking things usually comes with a cost, and delivering critical failure news to upper management is not without its risks. I’ve seen CIOs and CISOs lose their jobs due to a penetration test report. I’ve seen upper management and boards respond in entirely unkind and often undeserved ways. In fact, if you don’t know what assets your organization has to protect, what controls you have and/or haven’t done some level of basic blocking and tackling – forget pen-testing altogether and skip to an inventory, vulnerability assessment, risk assessment or mapping engagement. Save the pen-testing cost and dangerous results for when you have more situational awareness. 

Penetration testing is often good at finding the low water mark. It often reveals least resistant paths and common areas of failure. Unfortunately, these are often left open by a lack of basic blocking and tackling. While it’s good news that basics go a long way to protecting us and our data, the bad news is that real-world attackers are capable of much more. Finding those edge cases, the things that go beyond the basics, the attack vectors less traveled, the bad assumptions, the short cut and/or the thing you missed when you’re doing the basics well – that’s when penetration tests have their biggest payoffs.

Want to talk more about penetration testing, these lessons or finding the right vulnerability management engagement for your organization? No problem, get in touch and I’ll be happy to discuss how MicroSolved can help. We can do it safely, make sure it is the best type of engagement for your maturity level and help you drive your security program forward. Our reports will be clean, concise and well written. And, we’ll pay attention to the details, I promise you that. 🙂 

To get in touch, give me a call at (614) 351-1237, drop me a line via this webform or reach out on Twitter (@lbhuston). I love to talk about infosec and penetration testing. It’s not just my career, but also my passion.

A Quick Expert Conversation About Gap Assessment

Posted on by
Reply

Gap Assessment Interview with John Davis

What follows is a quick interview session with John Davis, who leads the risk assessment/policy/process team at MicroSolved. We completed the interview in January of 2020, and below are the relevant parts of our conversation.

Brent Huston: “Thanks for joining me today, John. Let’s start with what a gap assessment is in terms of HIPAA or other regulatory guidance.”

John Davis: “Thanks for the chance to talk about gap assessment. I have run into several HIPAA concerns such as hospitals and health systems who do HIPAA gap analysis / gap assessment in lieu of HIPAA risk assessment. Admittedly, gap assessment is the bulk of risk assessment, however, a gap assessment does not go to the point of assigning a risk rating to the gaps found. It also doesn’t go to the extent of addressing other risks to PHI that aren’t covered in HIPAA/HITECH guidance.”

BH: “So, in some ways, the gap assessment is more of an exploratory exercise – certainly providing guidance on existing gaps, but faster and more affordable than a full risk assessment? Like the 80/20 approach to a risk assessment?”

John Davis: “I suppose so, yes. The price is likely less than a full blown risk assessment, given that there is less analysis and reporting work for the assessment team. It’s also a bit faster of an engagement, since the deep details of performing risk analysis aren’t a part of it.”

BH: “Should folks interested in a gap assessment consider adding any technical components to the work plan? Does that combination ever occur?”

JD: “I can envision a gap assessment that also includes vulnerability assessment of their networks / applications. Don’t get me wrong, I think there is immense value in this approach. I think that to be more effective, you can always add a vulnerability assessment to gauge how well the policies and processes they have in place are working in the context of the day-to-day real-world operations.”

BH: “Can you tie this back up with what a full risk assessment contains, in addition to the gap assessment portion of the work plan?”

JD: “Sure! Real risk assessment includes controls and vulnerability analysis as regular parts of the engagement. But more than that, a complete risk assessment also examines threats and possibilities of occurrence. So, in addition to the statement of the gaps and a roadmap for improvement, you also get a much more significant and accurate view of the data you need to prioritize and scope many of the changes and control improvements needed. In my mind, it also gets you a much greater view of potential issues and threats against PHI than what may be directly referenced in the guidance.” 

BH: “Thanks for clarifying that, John. As always, we appreciate your expert insights and experience.”

JD: “Anytime, always happy to help.”

If you’d like to learn more about a gap assessment, vulnerability assessment or a full blown risk assessment against HIPAA, HITECH or any other regulatory guidance or framework, please just give us a call at (614) 351-1237 or you can click here to contact us via a webform. We look forward to hearing from you. Get in touch today!