Re: Better than most
Verisign meet Symantec.
Symantec, meet Google.
DigiCert, meet Symantec.
204 posts • joined 9 Feb 2014
"If a third party can fuck up enough business relationships to close down a company, that company is doing something fundamentally wrong."
Never heard of "the cloud", eh?
When you decide to outsource critical business functions to save money (which is never as much as promised) you have outsourced the future of your business.
Except the March security patch broke wireless networking on my older Windows 10 laptop with an Atheros card. No event logs, no service problems; it just would';t see any Wi-Fi points at all until I uninstalled it.
It's probably because of that "Designed for Windows Vista" RFID sticker on it, eh?
Bulletproof in my world includes physically separate switches, physically separate wiring and physically separate hosts. The term is "poka-yoke" which translates to mistake-proofing. Many, many incidents occur because of a misconfiguration caused by a human; Them doing something "just to see if it fixes the problem", doing something from memory, etc.
By physically separating the environment you remove much of the possible misconfiguration possibilities and the possibility of pivoting from an infected host to an isolated one. No more ACL problems, no more misconfigured VLANs, etc. They can still misconfigure them but the chances of that error causing a breach are dramatically reduced.
That being said you also need to remove the human element as much as possible. On one PCI penetration test I'm familiar with the company's internal network was 100% compromised in short order but they were absolutely unable to penetrate the PCI network. Right up until one tester said "I wonder what the chances are that some administrator used the same usename and password in both the production and PCI environments for convenience?" Yes, Game Over.
PCI now mandates that true two-factor authentication be used for access to the PCI cardholder data environment. They finally caught up to where we've been for years.
"Bulletproof" does not mean "following what the minimum controls are". It means performing threat modeling and admitting that one of the threats are your own people whether intentional or not. Believe it or not, some managers and HR people have a real problem with that type of thinking. :-)
P.Lee, your definition of "shoestring budget" and management's definition might be a wee different. :-)
There is a massive cost and complexity to subsidising anything owned and operated by someone else. The subsidy is a direct cost and the support is an indirect cost but they're both costs.
"You don't mix secure client systems with insecure client systems. No general internet access from a company system."
That's a great start but be prepared to hear the whining from the admins about how hard you've made their jobs.
Given that those are fairly intelligent people and undoubtedly have learned the lessons of OpenSSL and other bad implementations, I'm certain that as much as of that was as could be done during the threat modeling portion of the TLS 1.3 development was done. That's the value and danger of an open source protocol.; people can rip into it before it comes out.
Agreed. Thanks for taking the time to write that. One item that would concern me is this:
"Primarily we have email servers and web servers and the physical retail store in which the EPOS system is also Linux based, but said machine has no access to customer data and nor should it."
Actually card data is customer data. If you're soliciting it, it's considered your data if it's lost. At least in the USA. That statement coupled with this one:
"The only "remote login" feature of any of the systems is SSH which is setup to use keys instead of passwords (though the keys used do have passwords, so even if you lift my key you have to crack the (very, very, very long) password before you can use it, but I change the keys once per month so by the time you've cracked it, it may be useless)."
leads me to ask who supports your point-of-sale systems. For all small businesses it's a third-party and most POS breaches nowadays occur because of weak controls and weak remote access controls by the third-party. As you know, PCI now requires a certified installer to install those systems so it's pretty much a given that you have a third-party involved somehow. Even if you're strictly online you still have some liability via the use of an iframe or similar. Not nearly as much as physical terminals though.
"If someone is unsure whether an email is legitimate or not they are instructed to let me see it before going any further with it,"
When you rely on unreliable humans the control will fail. Perhaps you're small enough that the number of people with email is tiny.
"Users have the ability to add 2FA to their accounts" - If you're not requiring it, particularly if you're using that cesspool called "Office 365", you probably have a problem there.
"I also conduct my own pen-tests against our systems to see how far I can get seeing as I know the systems inside and out."
You seem reasonably knowledgeable but pen tests, particularly application pen tests, take an entirely different set of skills. You may have them; I do not. We once eval'd a proposed banking vendor who told us they had passed their last pen test with "flying colors". We always ask to see a copy of the full results but very, very few will do that. They did. They sent us a two-page printout of a NMAPv3 beta scan with safe checks enabled and with application checks disabled. After NMAP v4 was out. That raised a lot of alarm, we dug further and suffice it to say our customers are a lot safer because we declined to do business with them.
We do not run any ad networks or any other junk like that (so no google analytics or other spying networks,..."
If your employees, even the execs, have Internet browsing capabilities you've got them even if you're not running them on your systems.
None of this is meant as criticism. You seem to know your business and risks and that is kind of rare. Perhaps I've given you a few things to look over before bad things happen to you.
"Or possibly people will switch back to using plain HTTP between firewall and web server, which opens up other weaknesses."
Not "possibly". That is the common practice between the HTTPS-terminating load balancers and the back-end web servers. It allows far better automatic failover between the back-end web servers resulting in a better customer experience.
Why? Because if you run HTTPS between the load balancer and the web server you need to enable "stickiness" because the encryption is done between the load balancer and that web server only. So if the web server experiences problems, there's no way to seamlessly move you to another one and you get to fill in that ten-page form all over again (because you've never negotiated session keys with the other web server).
That HTTP connection is generally bullet-proof on both a physical layer and a logical layer. But if you're trying to run the back-end web servers in multiple physical locations the risk does go up.
"As for not being able to inspect data that is within encrypted traffic.. well isn't the whole point of encrypted traffic to stop just that?! Thankfully we don't try to do that anyway."
The adage about "You can't find what you don't look for" may apply here. I do work for a bank and we do crack TLS for browser (and other) traffic between the Internet and our systems. We've been graphing the number of legitimate but compromised HTTPS web sites and it just keeps on climbing. We used to see just a few each day but now that the ad networks are slowly moving their ads to HTTPS it's a few dozen each day.
If we were not doing this we would have far more malware incidents than we do now. On average we have to re-image one or two PC's a year for suspected malware out of 3,000+. I have friends working for law firms with less PC's who have multi-person teams re-imaging PC's full-time due to confirmed malware.
This is not a personal attack and it's something we hear from other companies all the time. "Oh, the horror! Our employees have a right to privacy!"
Yeah, well, guess what? The customers who have entrusted your company with their personal information also have a right to privacy and their right is legislated. My employer needs to protect the data of all our customers, not just yours.
These traffic inspection process for most corporations (not spies) are all automated. It's decrypted, inspected and re-encrypted. There is no storage and no retention unless something triggers an inspection rule and then only the part that fired the inspection rule is retained.
And if you got hit by the Equifax breach, one of the things they apparently did correctly was to have a full-packet capture device on their internal network. Like the spies, these devices capture, decrypt and store 100% of all network traffic. That's how they were able to definitely provide good detail on what happened. Without that device they could have claimed "We have no evidence that any data was stolen" and you might not even have been notified. So yeah, they bought a device that testified against them as to their problems. :-)
TLS 1.3 is just a ho-hum event. We'll still use TLS 1.2 between our employees and the proxy servers while allowing TLS 1.3 between the proxy servers and the Internet. Once TLS 1.3 is really ready, we'll allow TLS 1.3 from our employees to the proxies. Their HTTPS connections all terminate on the proxy server so they won't even notice. Even HSTS won't save them because HSTS doesn't have certificate issuer information.
As far as web sites go, everyone is using a reverse proxy or load balancers acting as reverse proxies anyway. The only companies that TLS 1.3 will negatively impact are those using span ports or taps to sniff the traffic off the wire as it goes past. The web sites that have no traffic inspection won't be impacted at all, just infected.
If you plan on replying about your super-dooper endpoint product that catches APTs and everything, feel free but you're wrong. Each endpoint is a single-point-of-failure and unless you have a NAC (network access control) system that will not permit the PC on to the network if its anti-malware is malfunctioning or not installed, you're just playing the compliance game and not the information protection game.Endpoint protection is needed but relying on it solely is...
Yet another occupational hazard. You can no longer travel to a country that has an extradition treaty with the charging country. Travel to Istanbul and get extradited to Russia. Or travel to Italy and get the "extraordinary rendition" treatment that Russia learned from the USA.
I don't use Blue Coat but it feels like the admin enabled a "Require TLS 1.3" option on the proxy thinking bigger numbers means better security. I see this all the time when non-security people get involved in security configurations.
While the spec for TLS 1.3 may be finalized, there are going to be implementation problems in the products for years.
SSL Labs checks a tiny, tiny part of what it means to secure a web site and the criteria they use is entirely up to them. Even an A+ means nothing as far as whether the site is coded, operated and maintained securely.
It's similar to a home inspector looking at the outside, seeing a gleaming new paint job and proclaiming the home in perfect condition even though it's about to collapse from termites, water damage, mold and being a former residence of the Turpin's.
Especially when the corporate folks decide to run DHCP centrally via IP Helper statements on the WAN routers and a problem back at corporate (Backhoe work took out WAN backup line but who cares? That thing goes don all the time.)
And an overnight drunk took out the pole carrying the WAN primary line on the other side of the campus and all of the salaried people kept getting paid while the hourly people sat around waiting for their computers to start working in the plants.
And the best part? All of their after-hours alerting was done by email and Internet was run on those two circuits as well, including the connection to the DR data center. "Wow, we got like no alerts overnight!"
Did you know that when you're in Active Directory Users and Computers and are going to delete something from the right-hand pane but accidentally are clicked in the left pane and say you're sure, it can delete the entire production OU? I know one sysadmin who now knows that and also is now far slower at his admin tasks. Until the next time...
"The hackers need to get within a meter or two of your keys, so their can 'illuminate' it with enough RF to power it up."
Actually it's the other way around. The car is continuously beaconing for the key fob because it has the battery power to do so. The attack uses a repeater that is close to the car (which is outside in a driveway or parking spot), amplifies the beaconing signal and thus triggers the key fob for a response even if the key is dozens of feet away inside the locked house.
The repeater picks up the key's reply amplifies it, and passes it to the car, unlocking the doors and allowing the car to be started and driven away. The countermeasure is to detect the miniscule delay caused by the repeater circuitry that would not be present if the key was next to the car. Previous reports show that almost no car manufacturers implemented that check.
Unless they are modulating or encoding the ping in some way specific to that car, yeah, it will work.
Decades ago a buddy picked up an old 10 GHz klystron-powered traffic radar. He built an audio modulator for it, impressed on the klystron's power supply, and by varying the frequency of the audio generator he could dial in any speed on the radar's speed display (mechanical needles at that time). Why? The AM modulation simulated the doppler shift that the traffic radars worked on. He figured out that if he got the AM modulation up to very close to 100% it would affect the cop's traffic radar (he could dial in any speed on their display because his transmitted signal was far more powerful than the reflection from their own radar transmitter).
Yes, we had some interesting drives in those days. Moving precisely at the speed limit, the Fuzz Buster goes off and once the cop has you clearly in view because no one else is near you, flip the switch to 125 MPH and watch their reaction all while staring straight ahead down the road to avoid them seeing you watching them.
Those things had an audio output so the cop could hear the doppler frequency so they knew it wasn't just an errant needle.
We had a fellow working in our department who got called up for duty in Afghanistan and was gone for a year and a half. He eventually came back to work and a year later he told us he was getting activated again. He was gone two days later but we heard he was stateside this time. We all breathed a sigh of relief.
I turned in my notice of resignation four months later and called him to say goodbye. The conversation went like this:
Me: "I wanted to let you know I'm leaving and won't see you when you get back. It was good working with you."
Him: "Same here, but what makes you think I'm ever coming back?"
Me, thinking he was telling me he was going back to Afghanistan: "Oh no, are you going back into combat?"
Him: "No. You don't really think I got activated again, do you?"
Me, confused: "Yes, that's what you said."
Him, laughing: "Heck no! I volunteered for activation because I hate that place so much. I was pretty sure I would be staying stateside but wasn't certain, though."
Me: "Wait, you hated your job so much that YOU VOLUNTEERED FOR ACTIVE DUTY DURING A WAR!!!!!!??????"
I'm still in awe of him.
"The executive summary is: companies should advise investors of risks, and use law enforcement investigations as an excuse to keep quiet."
What it actually says:
"We also recognize that it may be necessary to cooperate with law enforcement and that ongoing investigation of a cybersecurity incident may affect the scope of disclosure regarding the incident. However, an ongoing internal or external investigation – which often can be lengthy – would not on its own provide a basis for avoiding disclosures of a material cybersecurity incident."
Note the use of the word "not" in there.
"It also virtually identical to the advisory the SEC released in 2011, and the threat landscape, for want of a better buzzword, has changed considerably since then."
What it actually says:
"In addition, we address two topics not developed in the staff’s 2011 guidance, namely the importance of cybersecurity policies and procedures and the application of insider trading prohibitions in the cybersecurity context. "
And a nod to removing generic language:
"We expect companies to provide disclosure that is tailored to their particular cybersecurity risks and incidents. As the Commission has previously stated, we “emphasize a company-by-company approach [to disclosure] that allows relevant and material information to be disseminated to investors without boilerplate language or static requirements while preserving completeness and comparability of information across companies.”Companies should avoid generic cybersecurity-related disclosure and provide specific information that is useful to investors."
Some previous wiggle room got removed:
"For example, if a company previously experienced a material cybersecurity incident involving denial-of-service, it likely would not be sufficient for the company to disclose that there is a risk that a denial-of-service incident may occur."
And a smackdown to Equifax:
"Additionally, directors, officers, and other corporate insiders must not trade a public company’s securities while in possession of material nonpublic information, which may include knowledge regarding a significant cybersecurity incident experienced by the company."
Note the use of the word "must" in there, a term rarely used in government guidance?
Perhaps a vulture needs new glasses or read the 2011 guidance by mistake. :-)
In my high school electronics class, early '70's, we were breadboarding five tube AM radios. You know, real voltages and currents, not this wimpy low-voltage stuff. One team had to build in a fault and the other team had to troubleshoot it. My team member and I realized that most of the class was simply "troubleshooting" by looking at the physical layout of the parts and jumper wires on the breadboard.
So we laid out the parts so the radio worked but with the parts scattered all over the place. For example, the antenna was no longer in the upper left-hand corner and the speaker was no longer in the lower right-hand corner and the Intermediate Frequency amplifier was no longer in the center.
One of the changes we came up with was to place the tube plate load resistor right next to the cathode bias resistor. If you're never worked on vacuum tube stuff, the plate resistor had roughly 250 volts applied with several milliamps flowing through it. The cathode resistor was the exact opposite. It developed its potential (voltage) by the flow of the current through the tube. So it had very low voltage and its components, particularly the cathode bypass capacitor, was rated at a very low voltage.
Anyway, the power supply was up on a shelf and we didn't have long leads so the 250 volt plate wire was stretched like a guitar wire to the far end of the breadboard because we had re-arranged the parts layout. (All of the connections were uninsulated alligator clips <- important point).
While the other team was trying to find the fault by pushing and prodding, they bumped the taut plate power wire. Its alligator clip moved slightly and now also touched the cathode lead of the tube. Not only did this give them a second problem to find, it put 250 volts across the cathode bypass capacitor rated at 6 volts DC. The ammeter on that Heathkit power supply pegged out at 250 milliamps.
Why didn't the fuse in the power supply blow? Because we were always blowing those fuses through mistakes so we put in oversized ones. Why? Because the instructor yelled at us for using up his fuses, of course.
Fascinated, we watched that power supply push over a quarter-amp through that poor capacitor but nothing happened. After a few minutes the two of us decided to wander to the other side of the room so we would not be near the breadboard whenever what was going to happen happened.
A few minutes later, with the two "troubleshooters" hunched over that board and oblivious to the high current, a very, very loud bang occurred followed by non-flaming confetti. The two students fell off their metal stools to the concrete floor but fortunately neither were injured.Smoke filled the lab.
They and the instructor were very mad at us but since we were far away when it happened, we denied any knowledge. We looked over the breadboard and pointed out the short circuit we already knew about. No proof meant no suspension.
That capacitor did not shoot anyone's eye out but it easily could have. Lesson learned about wearing safety glasses.
The Chinese probably did a real audit to make sure no American backdoors were present or that the ones they installed at Nortel were already gone. Imagine their surprise... :-)
https://www.theregister.co.uk/2012/02/15/nortel_breach/ - "Whistleblower: Decade-long Nortel hack 'traced to China."
Heresy, right? Not really.
If your company is really taking the topic seriously they will set a DNS CAA record. It's a TXT record for Certificate Authority Authorization and lists the CA's allowed to issue certificates for your domain and subdomains. ALL CA's are required to check for the presence of that record. No record means any CA can issue a certificate.
Use Let's Encrypt, even with a CAA record, and yeah, you know what they say about "free" products... From their FAQ: "Let’s Encrypt is run by a small team and relies on automation to keep costs down. That being the case, we are not able to offer direct support to our subscribers." That does not give me a warm and fuzzy feeling. They are providing a great service but my opinion is it's not for security-centric organizations.
Use a real, paid-for CA and list them in your CAA record. You'll have two-factor logins for your account and probably IP address restrictions. That will keep someone from creating TLS certs for your domain without your knowledge unless they can social engineer the CA into lifting the source IP address restriction as well.
Just as importantly, see if your domain registrar can set a "lock" on your domain registration at the top level domain. That will create a multi-step process involving PINs and phone callbacks before changes will be permitted to the authoritative DNS servers. It pretty much eliminates the most common domain hijacking attack.
No, I do not work for a CA or a registrar.
This site will help you learn about CAA records and can give you the needed syntax as well as test your record: https://sslmate.com/caa/
No, I have no affiliation with them. They also have a Certificate Spotter service, free for up to five domains, which will alert you if a certificate is issues for your domain.
On a recent internal penetration test the red team worked for two weeks and the company's fancy dancy Intrusion Detection System, which we shall refer to by its code name of SnortFire, missed 100% of the activity.
Why? Apparently they saw a job posting for someone with skills on that system so they just proactively evaded it. Double why it missed everything? Because the vendor's own people told the company that many of its detections had to be disabled because they were too "performance-impacting".
If a company really wants to improve their security, they need to get rid of the well-liked 20-year tenure managers who have let their skills and training erode to the point where all of their recommendations sound great to the uneducated but in reality are worse than useless. They'll also save a buttload of money.
"... unless you've previously compromised legitimate sites for it."
And according to our proxy, a LOT of attackers have gone that route. The vendor's block page says "Compromised Site" so we changed the wording to "This website has been HACKED!" and we still get maroons complaining that they HAVE to get to that site for some kind of obviously personal business. We tell them they'll need to do it from their phone or home computer. That should tie them up for hours getting that mess cleaned up and thus out of our hair. Darwin's First Law of Computer Users, I guess.
And wants to discuss our plans in security research and strategy while extolling the virtues of using their security services. I told the person that we do our own security research and offered to send them a copy of a recent report we created for their evaluation to see how it could be improved. They happily agreed.
I sent them the link to the recent The Register article on how IBM has screwed up their response to Meltdown and Spectre issues with their customers.
Oddly, the salesperson has not contacted me back yet.
Yup, it showed up on my PC tonight, before Patch Tuesday, and a family member saw it and applied it dutifully, just like I told them they should always do. The Windows automatic startup repair would not work. I could use one of its options to rollback to the Restore Point it created before it installed and all is well now. And Check For Updates is now turned off.
This was an HP desktop. My Compaq desktop also has an AMD processor so I removed its power cord for now. Both are 10+ years old and started out on Vista but are running perfectly for the limited use they see.
When a new technology is proposed by the devs I always check the job postings for it on Dice and Indeed. If no one is hiring for it it's not a good technology. They once wanted to start using Microsoft Lightswitch. Everything pointed to Lightswitch being a dead product, even Microsoft's tech blog hadn't had an update in over a year. There were more postings for electricians using the word "light switch" than developers on Indeed, because that;s clearly where all of the really good electricians hang out, and more posts for Silverlight developers after everyone knew it was a DOA product.
But because mgmt is so smart we went with it anyway. And two years later dumped it and rewrote everything because it would not scale, just like all of the evidence said. Apparently we don't have the time to do it right the first time but we do find the time to re-do it. :-)
Juniper has lost double-digit sales in their alleged "security" line for at least six quarters. Yes, in the fastest growing marketspace that is only projected to keep climbing they are losing market share and sales. They claim the SRX is an integral part of their SDN offering. If that's accurate then their SDN offering is losing sales as well because you can't sell one without the other. Their IPS offering with the SRX is a poor joke compared to other vendors. They sold off their only other semi-security product, the SSL VPN they got from Neoteris, to Pulse Secure years ago and that leaves them with just the SRX. And of course, ACLs. Stop throwing good money after bad and do a partnership with a true security vendor and no, that is not Cisco.
Sure, as long as you agree to not complain or demand your money back when it was caused by you using your debit card at a standalone kiosk in a mom-and-pop store. Or because you allowed Microsoft Tech Support to remote in to fix a virus. Or because you just KNOW you won that car in a lottery you did not enter and just need to pay the taxes. Or because your grandson was arrestedy and doesn't want his parents to know so he asks you for bail money.
"Up to 40%"? How much really? Please use real numbers not media corporate-speak nonsense. "We lost a limited number of customer records" which can translate to all but one.
We've been monitoring TLS at the bank I work for since 2014. Non-TLS 1.2 (not TLS 1.1; nobody uses that) has been at 1.5% (notice the dot?) for over a year.
TLS 1.1 has been below one percent since we started monitoring and is now below one one-hundredth of a percent.
Clearly the author has never looked at the HTTPS traffic on even a medium-sized business, say a thousand employees. On any given day there are between two and dozens of stops for compromised legit sites serving up malware over HTTPS.
This proposal just adds another covert channel for malware infiltration and data exfiltration. If you want to make a sysadmin's job hard, get yourself hacked by one of your endpoints and end users.
The local media loves to do these types of articles and I love them for it. Why? Because they have no clue what they're doing so we always look great.
- They never chase links so they never test our online banking systems or our online account opening sites, which are on separate servers from the brochureware home page.
- They never check DNS configurations to see if we have CAA, SPF, DKIM, or DMARC records deployed.
- They never check to see if we allow DNS zone transfers from arbitrary IP addresses, not only revealing systems publicly that we don;t want the world to know about but that also allows us to be used in DDoS attacks,.
- They never check the robots.txt files to see if we're using them as a form of security through obscurity.
- They never check email DNS records to see if we have over one million IP addresses listed in our SPF record because of Office 365 usage. Or are using +all in it
- They never use a real website testing service like observatory.mozilla.org so The Big D does not show on sites that SSL Labs rates as an A: https://observatory.mozilla.org/analyze.html?host=santander.com
Keep up the good work, folks!
Don't worry. NIST has them covered. There's no need to regularly change passwords unless you know they've been compromised and those clueless* companies not only did not have low lockout thresholds set or they could not have been brute-force, I'm fairly certain they do not know they've been compromised. Those accounts will be valid for a long time.
"The opposite of secure is not insecure. The opposite of secure is convenient."
*The very definition of clueless on the Internet is exposing administration services directly to the entire world.
None of the comments directly touched on the initial infection vector so here it is: STOP PUTTING YOUR SERVERS DIRECTLY ON THE INTERNET.
Shodan showed that both NHS and Telefonica had servers with every default port open to the Internet, including SMB. Perhaps some well-meaning obsolete not-competent-for-this-position manager overrode the techies with a "But the file share requires a username and password so just do it!"
Biting the hand that feeds IT © 1998–2020