Author Archives: James Klun

About James Klun

Eldergeek - 30+ years of Mainframe/Unix/etc systems programming, administration, and technical management. 15+ years of Infosec. Endless amounts of what might pass for English prose. "We have met the enemy, and he is us": http://en.wikiquote.org/wiki/Walt_Kelly

The mathematician as extortionist: ransomware “smart” contracts

Posted on by

The mathematician as extortionist: ransomware “smart” contracts

Source: https://en.wikipedia.org/wiki/Brazen_head

A few weeks ago I wrote about the “proof of work” concept inherent in the implementation of the blockchain used to support bitcoin.  I have continued down the blockchain path and have been exploring another child of the blockchain revolution:  Ethereum.

Continue reading →

Bitcoin “Proof of Work”: 51% of Accountants Agree!

Posted on by

Bitcoin “Proof of Work”: 51% of Accountants Agree!

Source: Fox Photos/Getty Images

Those are the “accountants”, all working independently to validate bitcoin transactions.

I’ve read the original white-paper that is often cited as the foundation of the cryptocurrency, and particularly the “bitcoin“, phenomenon.

See: https://bitcoin.org/en/bitcoin-paper

The author is the mysterious “Satoshi Nakomoto“, who may be Japanese, or may be a collection of people, or may be (my take) some blockchain instance from the future that has developed self-awareness and has traveled back through time, using the identity of Satoshi to create itself.

Continue reading →

Positive Train Control: Skating away on the thin ice of a new day?

Posted on by

Positive Train Control: Skating away on the thin ice of a new day?

From the movie “The Polar Express“

That line: “Skating away on the thin ice of a new day” is from a Jethro Tull song by the same name. (Yes – I am that old 😉 ).

It came to me as I was reflecting on the reading I’ve been doing on the topic of “Positive Train Control“ (PTC).

PTC is an idea rather than any specific technology or architecture.  Continue reading →

Stopping the Flow of Business: EDI as a Natural Gas Pipeline Attack Vector

Posted on by

In the not too-distant past I was involved in helping secure the information infrastructure of a major EDI “VAN”.

How’s that  for gibberish?   Some definitions are in order:

EDI = “Electronic Data Interchange”.  Effectively, a collection of standards for the encoding of documents such as invoices, purchase orders, bills of lading, medical information, and – it seems – information pertaining to the business of buying, selling and moving natural gas.

EDI dates from the 1970’s. It took advantage of pre-Internet communication mechanisms but quickly was adapted to the Internet and likely will be to blockchain.

EDI “trading partners” can communicate directly, but often they rely on  third-party EDI specialists to handle communication with their various trading partners.  These are the EDI “Value Added Networks” (VAN).

EDI is the unsung hero of modern commerce.

Everything we buy or sell has a secret life as an EDI document. Usually a number of them.

Not surprisingly, natural gas pipeline companies use EDI in the running of their business, communicating information about availability and pricing to their customers and government.  A few months ago,  the business of some natural gas pipeline companies was disrupted by the sudden unavailability of those EDI services.

The attack, in March 2018, was directed against a central provider of EDI services to several major natural gas pipeline operators. Although it did not affect actual in-field operations, it did stop all normal business traffic for several days, causing confusion and a fall-back to alternate communication mechanisms.

Of greater concern was the loss of potentially sensitive information about internal business structure, all of which can be inferred from the ebb and flow of EDI data.  Such information can be invaluable to an attacker and in this case can be an aid in eventually attacking actual pipeline operations.

The point here is that it is easy to view such operations as strictly an ICS security concern, and that with proper segmentation of business from ICS infrastructure all will be well.

I’ve had some experience in that ICS world over the last few years and know that segmentation is often incomplete at best. Even when segmentation is present, your business can still be vulnerable to attacks on exposed business systems that have process flow links to ICS.

What to do?

  • Know how you use EDI and what your supporting infrastructure is.
  • Know who your EDI providers are and what security measures they employ
  • Do a business impact analysis of your EDI environment. What happens if it goes away?
  • Ensure you really do have segmentation of your business and ICS worlds. Make sure the places they touch are known, secured, and monitored.

 

See:

EDI defined: 

https://www.edibasics.com/what-is-edi 

https://en.wikipedia.org/wiki/Electronic_data_interchange

https://www.edibasics.com/edi-resources/document-standards

Natural Gas Industry Usage of EDI:

http://latitudestatus.com/

https://www.naesb.org/pdf4/update031413w4.docx

Quote: “The NAESB wholesale natural gas cybersecurity standards facilitate an infrastructure of secure electronic communications under which the electronic transmission of data via EDI or browser based transactions is protected. There are more than fifty separate transactions identified for nominations, confirmations, scheduling of natural gas; flowing gas transactions including measurement, allocations, and imbalances; invoicing related transactions including invoices, remittances, statement of account; and capacity release transactions.”

https://www.edigas.org/faq/

http://www.rrc.texas.gov/oil-gas/applications-and-permits/oil-gas-edi-filing-deadlines/

The Attack:

https://www.eenews.net/stories/1060078327

http://securityaffairs.co/wordpress/71040/hacking/gas-pipeline-operators-hack.html

https://www.bloomberg.com/news/articles/2018-04-03/day-after-cyber-attack-a-third-gas-pipeline-data-system-shuts

EDI Security:

https://www.acsac.org/secshelf/book001/18.pdf

Quote:  “EDI security appears at several interrelated stages:

  • The user/application interface,
  • EDI applications and value added services,
  • The processing (both batch and interactive) and storage of EDI messages,
  • The communication of these messages in an open systems environment”

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

It’s a cyberwar, and you are the target.

Posted on by

The Target?  You.                               Image Source: Wikimedia Commons

The U.S. Department of Justice’s indictment of the Russian operatives (July 13, 2018) who successfully compromised DCCC and then DNC computers makes for some interesting reading.

Some excerpts:

  • “….<the Russian operatives> were dedicated to targeting military, political, governmental, and non-governmental organizations with spearphishing emails and other computer intrusion activity.”
  • ——————–
  • “….used various online personas, including “Kate S. Milton,” “James McMorgans,” and “Karen W. Millen,”
  • ——————–
  • “….sent spearphishing emails to members of the
    Clinton Campaign and affiliated individuals, including the chairman of the Clinton Campaign”
  • ——————–
  • “….. altered the appearance of the sender email address in order to make it look like the email was a security notification from Google (a technique known as “spoofing”), instructing the user to change his password by clicking the embedded link. Those instructions were followed. On or about March 21, 2016, LUKASHEV, YERMAKOV, and their co-conspirators stole the contents of the chairman’s email account, which consisted of over 50,000 emails.“
  • ——————–
  • “… created an email account in the name (with a one-letter deviation from the actual spelling) of a known member of the Clinton Campaign. The Conspirators then used that account to send spearphishing emails to the work accounts of more than thirty different Clinton Campaign employees. In the spearphishing emails, LUKASHEV and his co-conspirators embedded a link purporting to direct the recipient to a document titled “hillary-clinton-favorable-rating.xlsx.” In fact, this link directed the recipients’ computers to a GRU-created website“
  • ——————–
  • “…used an email account designed to look like a Vendor 1 email address to send over 100 spearphishing emails to organizations and personnel involved in administering elections in numerous Florida counties. The spearphishing emails contained malware that the Conspirators embedded into Word documents bearing Vendor 1’s logo.

That last one strikes close to home for me as it is a technique I have used successfully when conducting “white-hat”  phishing exercises for MSI’s clients.

The indictment makes it clear that we are very much in a “cyberwar” right now and that the targets of greatest opportunity in that war are not information infrastructure – but people. You and I, feverishly pounding away at a keyboard in an attempt to meet some deadline (like writing a blog post?).  Or, even better and more dangerous, responding to emails with a mobile device while we sit waiting at a stoplight. None of us, of course.

Many of you likely regard yourselves as targets of little interest in any cyberwar attack. And that may be true for you specifically, but is it true of your family members and friends as well?

Perhaps one of them works for an HVAC vendor that does work for government?

The point is that everyone is connected via some device and everyone shares infrastructure (cloud storage?) with others.  Any person in that chain of connectedness is a potential stepping stone to items of real interest to an attacker.

Phishing has become the primary attack vector and the target can be anyone who is connected to someone else with access to sensitive information. It’s low cost and relies on information about us that we and those who know us have freely given up,

And… it just works. Those Russian operatives know that, and so should you.

Everyone is now a potential target in this new type of warfare

What to do?

  • Make sure you, your family members, and your co-workers have a basic understanding of phishing and what to look out for.
  • ——–
  • If your company provides training on phishing awareness, take it seriously. If it has none, lobby for it.
  • ——–
  • If you are in management, realize that your employees are the new attack surface. Make sure they are trained to detect phishing and are willing to report it – even if they think they may have been successfully phished. That last is important. Your company will be the real loser if employees are afraid to speak out. Do not rely on magic-bullet technology alone to address what is fundamentally a problem in human behavior. . Conduct periodic tests to see how aware your people really are. No punishment – education!
  • ——–
  • Use Multifactor Factor Authentication (MFA)! If an attacker obtains your traditional login credentials (login/password) and that’s all you use, they have you. Multifactor authentication requires the addition of “something you know” or “something you have”.  Typical examples involve login sequences that require you enter a one-time code texted to your phone (“something you have”). Adding that extra factor complicates the whole phishing process and may even render it futile. All modern infrastructure supports some form of MFA.
  • ——–
  • Keep your work environment separate from your home environment. Consider segmenting your home network. A unique “work” wifi environment, with separate IP addressing, used only for your work (no family members, guests, or IOT devices) may be a good place to start.

See:

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

Update:  The war continues: https://www.npr.org/2018/07/28/633056819/russian-hackers-targeted-the-most-vulnerable-part-of-u-s-elections-again

 

 

 

 

 

 

 

 

 

Let’s Talk… But First “Let’s Encrypt”!

Posted on by

One of the common findings security assessment services encounter when they evaluate the Internet presence of an organization are sites where login credentials travel over the Internet unencrypted.

So: HTTP not HTTPS.

You’ve all seen the “not secure” warnings:

The intent of the browser’s warning is to make the user aware that there is a risk of credential loss with this “http-only” unencrypted login.

The solution is HTTPS of course, but that requires that a “certificate” be created, signed by some “certificate authority” (CA), and that the certificate be installed on the website.

If the user connects via HTTPS ( not HTTP ) the browser and the server negotiate an encrypted communication channel based on the SSL/TLS protocol and all is well…. almost.

The traffic will be encrypted, but if the particular CA that created the website’s certificate is not itself known to the browser (and those trusts are either built-in or added by an IT department) the user may see something like the following:

The browser will give the user the option to trust the certificate and proceed – but this is universally regarded as a bad practice as it makes the end user more inclined to disregard all such security warnings and thus be more susceptible to phishing attacks that intentionally direct them to sites that are not what they claim to be.

The usual solution is to purchase certificates from a known and accepted CA (e.g. DigiCert, Comodo, GoDaddy, Entrust, etc.).

The CA’s that issue these certificates will perform some checks to ensure the requester is legitimate and that the domain is in fact actually controlled by the requester. The extent to which identity is verified and the breadth of coverage largely determines the cost – which can be anywhere from tens to thousands of dollars.  SSLShopper provides some examples.

Users who browse to such sites will see the coveted “green lock” indicating an encrypted HTTPS connection to a validated website:

The problem is the cost and administrative delay associated with purchasing certificates from accepted CA’s, keeping track of those certificates, and ensuring they are renewed when they expire.

As a result some sites either dispense with HTTPS altogether or rely on “self-signed” certificates with the attendant risk.

This is where  “Let’s Encrypt” comes in.

“Let’s Encrypt” is an effort lead by some of the major players in the industry to lower (read: eliminate) the cost of legitimate HTTPS communications and move the Internet as much as possible to HTTPS (and other SSL/TLS encrypted traffic) as the norm.

The service is entirely free and the administrative costs are minimal. Open-source software (Certbot) exists to automate installation and maintenance.

Quoting from the Certbot site:

“Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your webserver. Certbot was developed by EFF and others as a client for Let’s Encrypt … Certbot will also work with any other CAs that support the ACME protocol.…

Certbot is part of EFF’s larger effort to encrypt the entire Internet. Websites need to use HTTPS to secure the web. Along with HTTPS Everywhere, Certbot aims to build a network that is more structurally private, safe, and protected against censorship”

The software allows “Let’s Encrypt” – acting as a CA – to dynamically validate that the requester has control of the domain associated with the website and issue the appropriate cert.  The certificates are good for 90 days – but the entire process of revalidation can be easily automated.

The upshot is that all the barriers that have prevented universal adoption of HTTPS have largely been removed.  The CA’s economic model is changing and some have left the business entirely.

Do you still have HTTP-only sites and are they a chronic finding in your security assessments?

Has cost and administrative overhead been a reason for that?

Take a look at “Let’s Encrypt” now!

One caveat:

Just because a site has a legitimate certificate and is using HTTPS does NOT mean it is necessarily safe,  You may find your users are under the impression that is the case. As always, user education is a required part of your security program.

See:

HTTPS:

 

“Let’s Encrypt”:

User Education:

Is your website in a “bad” neighborhood?

Posted on by

If, when you wake up in the morning, you look out outside and view something like the image below, you probably understand that you are not in the best of all possible worlds.

So, what “neighborhood” does your website see when it “wakes up”?

It could be just as disquieting.

It is not uncommon for MSI to do an an analysis of the Internet services offered by an organization and find that those services are being delivered from a “shared service” environment.

The nature of those shared services can vary.

VM Hosting:

Often they are simply the services of an virtual machine hosting provider such as Amazon AWS. Sometimes we find the entire computing infrastructure of a customer within such an environment.

The IP addressing is all private – the actual location is all “cloud”.

The provider in this case is running a “hypervisor” on it’s own hardware to host the many virtual machines used by its clients.

Application Hosting:

Another common occurrence is to find third-party “under the covers” core application services being linked to from a customer’s website. An example of such a service is that provided by commercial providers of mortgage loan origination software to much of the mortgage industry.

For example, see: https://en.wikipedia.org/wiki/Ellie_Mae

A quick google of “site:mortgage-application.net” will give you an idea of the extent to which the service is used by mortgage companies. The landing sites are branded to the customer, but they are all using common shared infrastructure and applications.

Web Site hosting:

Most often the shared service is simply that provided by a website hosting company. Typically many unique websites are hosted by such companies. Although each website will have a unique name (e.g. mywebsite.com) the underlying infrastructure is common. Often many websites will share a common IP address.

It is in this particular “shared service” space we most often see potential issues.

Often it’s simply a reputation concern. For instance:

host www.iwantporn.net
www.iwantporn.net is an alias for iwantporn.net.
iwantporn.net has address 143.95.152.29

These are some of the sites that are (or have recently been) on that same IP address according to Microsoft’s Bing search engine:

My guess I some of the website owners would be uncomfortable knowing they are being hosted via the same IP address and same infrastructure as is www.iwantporn.com.

They might also be concerned about this:

https://www.virustotal.com/#/ip-address/143.95.152.29

Virustotal is reporting that a known malicious program was seen  communicating with a listening service running on some site with the IP address 143.95.152.29 .

The implication is that some site hosted at 143.95.152.29 had in the past been compromised and was being used for communications in what may have been a ransomware attack.

The IP address associated with such a compromised system can ultimately be blacklisted as a known suspicious site,

All websites hosted on the IP address can be affected.

Website traffic and the delivery of emails can all be affected as a result of the misfortune to share an IP address with a suspect site.

“Backplaning”

When such a compromise of the information space used by a client in a shared service occurs, all other users of that service can be at risk. Although the initial compromise may simply be the result of misuse of the website owner’s credentials (e.g. stolen login/password), the hosting provider needs to ensure that such a compromise of one site does not allow the attacker to compromise other websites hosted in the same environment – an attack pattern sometimes referred to as backplaning.

The term comes from electronics and refers to a common piece of electronics circuity (e.g a motherboard, an IO bus, etc. ) that separate “plugin” components use to access shared infrastructure.

See: https://en.wikipedia.org/wiki/Backplane

Example:

The idea is that a compromised environment becomes the doorway into the “backplane” of underlying shared services.  (e.g. possibly shared database infrastructure).

If the provider has not taken adequate precautions such an attack can affect all hosted websites using the shared service.

Such things really can happen.

In 2015 a vulnerability in commonly used hypervisor software was announced. See:  http://venom.crowdstrike.com/

An attacker who had already gained administrative rights on a hosted virtual machine could directly attack the hypervisor and – by extension – all other virtual machines hosted in the same environment. Maybe yours?

What to do?

Be aware of your hosted environment’s neighborhood. Use the techniques described above to find out who else is being hosted by your provider. If the neighborhood looks bad, consider a dedicated IP address to help isolate you from the poor administrative practices of other hosted sites.

Contact your vendor to and find out what steps they have in place to protect you from “backplane” attacks and what contractual protections you have if such an attack occurs.

Questions?  info@microsolved.com

Hotel Wifi = Raw Internet. A true story.

Posted on by

A friend on a road-trip recently had an experience using hotel wifi that was a little surprising.  For several hours, while on the hotel’s wifi, her machine was effectively on the open Internet with no intervening firewall,

Her laptop was instrumented with one of MSI’s “honeypoints“, a lightweight honeypot that emulates various services and reports back to a central console when these “fake” services are interacted with, possibly by an attacker.

Over the several hour period while on wifi, the following Internet probes (and in some cases clear attacks) were seen.

The attacker IP and the port probed are in bold below:

  • Jan 15 18:03:43 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:42 Alert Data: Connection Received  ==> https probe
  • Jan 15 18:03:49 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:48 Alert Data: GET / HTTP/1.1#015#012Host: 63.140.158.108#015#012#015
  • Jan 15 18:03:49 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:48 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2215.txt
  • Jan 15 18:23:02 HPSS012 HPSS Agent: Tarsus.local received an alert from: 181.214.87.7 on port 3389 at 2018-01-15 18:23:02 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2216.txt  ==> Terminal services probe from Sweden
  • Jan 15 20:06:21 HPSS012 HPSS Agent: Tarsus.local received an alert from: 209.126.136.7 on port 443 at 2018-01-15 20:06:20 Alert Data: Connection Received
  • Jan 15 20:06:29 HPSS012 HPSS Agent: Tarsus.local received an alert from: 209.126.136.7 on port 443 at 2018-01-15 20:06:28 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2217.txt
  • Jan 15 20:20:36 HPSS012 HPSS Agent: Tarsus.local received an alert from: 189.219.71.36 on port 23 at 2018-01-15 20:20:35 Alert Data: cat /proc/mounts; (/bin/busybox BBFMC || )  ==> Port 23 (telnet) IOT attack from Mexico. Likely from a Mirai botnet variant.
  • Jan 15 20:26:22 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:21 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2218.txt  ==> Microsoft SQL Server probe from Guam
  • Jan 15 20:26:22 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:22 Alert Data: Connection Received
  • Jan 15 20:26:33 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:32 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2219.txt
  • Jan 15 22:03:44 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.199.113.84 on port 1433 at 2018-01-15 22:03:43 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2220.txt  ==> SQL Server probe from U.S. 

These alerts were being reported to the console from the IP address assigned by the hotel to my friend’s laptop: 63.140.158.108

That IP is registered to:

NetRange: 63.140.128.0 – 63.140.255.255
CIDR: 63.140.128.0/17
NetName: WAYPORT-63-140-182-NET

Wayport is an ATT wifi service providing “hotspots” to various large companies.

These are the types of probes and attacks a box on the open Internet can expect to get. It’s become like cosmic radiation – pervasive. I discussed a previous related event here:  https://stateofsecurity.com/?p=4126

What is interesting in this case is the fact they happened at all.

The hotel was part of a major chain.  The common assumption is they are watching out for their guests to ensure a “safe” wifi environment…and in general they are.

But – there maybe some fine print.

Some hotel wifi agreements apparently specifically allow you to request “advanced” connectivity options, in some cases as a result of wanting to do VPN from your laptop.  The result of those decisions may lead to a public Internet address and full Internet exposure of your device .

So – no Internet firewall but the one you bring with you.

Bottom Line:

  • Regardless of the cause, you should expect the worst from “free” wifi.
  • Assume full Internet exposure and have a software firewall enabled that blocks unsolicited inbound traffic.

See:

Quote from that last:

“Most private LANs use network firewalls to defend trusted insiders against Internet-borne attacks.This is not necessarily true in hotel broadband LANs, where topologies and security practices vary widely.For example, some use private IP addressing, while others assign each user their own public IP address to facilitate VPN tunneling. Users may assume they are insulated from outsiders, but really have no idea whether any firewall lies between
their notebook and the Internet. Notebooks that do not firewall themselves or that use certain applications that open holes in firewalls could thus be exposed to intrusions from the far side of the Internet.”

You need your own “cop on the beat”: Why security scanning services are not enough.

Posted on by

He knows what “normal” is. Source: Wikimedia Commons

I have repeatedly had the experience of performing external vulnerability assessments and discovering significant issues that were not being called out as such by the regular commercial assessment services employed by the client organization.

I recently discovered a case where active web server logs were freely available on the open Internet .  The usual information – source IP address, target resource, and status codes –  were all available.

Example:

64.39.99.99 – – [02/Aug/2017:10:09:07 -0400] “GET /client/chat.php?id=1%22%20%3E%3C/script%3E%3Cscript%3Ealert%28%27QualysXSSTestPart2%27%29%3C/script%3E&xhash=1 HTTP/1.1” 302 433 “-” “-“
64.39.99.99 – – [02/Aug/2017:10:09:08 -0400] “GET /index.do HTTP/1.1” 302 301 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:10 -0400] “GET /userui/welcome.php HTTP/1.1” 302 311 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:12 -0400] “GET /struts2-rest-showcase/orders HTTP/1.1” 302 321 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:08:58 -0400] “POST /rest/json/login HTTP/1.1” 302 308 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:14 -0400] “GET /node.xml HTTP/1.1” 302 301 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:14 -0400] “GET /user/login HTTP/1.1” 302 303 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:15 -0400] “GET / HTTP/1.1” 302 293 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:16 -0400] “GET /admin.php HTTP/1.1” 302 302 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:16 -0400] “GET /console/login/LoginForm.jsp HTTP/1.1” 302 320 “-” “-”

The highlighted entry is a “cross site scripting” (XSS) test being run over the Internet by the vulnerability management service “Qualys“.

From “whois 64.39.99.99”

NetRange: 64.39.96.0 – 64.39.111.255
CIDR: 64.39.96.0/20
NetName: QUALYS

Anyone on the Internet was able to view these logs and learn of the organization’s use of Qualys and something of the types of tests being performed and what the outcome of those tests were.

All highly useful information to any potential attacker.

Note that the problem here is NOT with Qualys.

The site that allowed these logs to be revealed had no “technical” security problem. Any internal user who was basing their understanding of the external security status of the organization strictly on the scanning service reports would likely have no reason to believe anything was wrong.

Your organization needs at least one knowledgeable and caring staff member whose job it is to know what your organization looks like from the Internet and can see when something is clearly wrong in the same way a neighborhood patrol officer can notice a strange car or a gate open that is normally locked.

You need your own “cop on the beat”.