What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2020-04-07 11:28:11 | If You Can\'t Patch Your Email Server, You Should Not Be Running It (lien direct) |  CVE-2020-0688 Scan Results, per Rapid7tl;dr -- it's the title of the post: "If You Can't Patch Your Email Server, You Should Not Be Running It."I read a disturbing story today with the following news:"Starting March 24, Rapid7 used its Project Sonar internet-wide survey tool to discover all publicly-facing Exchange servers on the Internet and the numbers are grim.As they found, 'at least 357,629 (82.5%) of the 433,464 Exchange servers' are still vulnerable to attacks that would exploit the CVE-2020-0688 vulnerability.To make matters even worse, some of the servers that were tagged by Rapid7 as being safe against attacks might still be vulnerable given that 'the related Microsoft update wasn't always updating the build number.'Furthermore, 'there are over 31,000 Exchange 2010 servers that have not been updated since 2012,' as the Rapid7 researchers observed. 'There are nearly 800 Exchange 2010 servers that have never been updated.'They also found 10,731 Exchange 2007 servers and more than 166,321 Exchange 2010 ones, with the former already running End of Support (EoS) software that hasn't received any security updates since 2017 and the latter reaching EoS in October 2020."In case you were wondering, threat actors have already been exploiting these flaws for weeks, if not months.Email is one of, if not the most, sensitive and important systems upon which organizations of all shapes and sizes rely. The are, by virtue of their function, inherently exposed to the Internet, meaning they are within the range of every targeted or opportunistic intruder, worldwide.In this particular case, unpatched servers are also vulnerable to any actor who can download and update Metasploit, which is virtually 100% of them.It is the height of negligence to run such an important system in an unpatched state, when there are much better alternatives -- namely, outsourcing your email to a competent provider, like Google, Microsoft, or several others.I expect some readers are saying "I would never put my email in the hands of those big companies!" That's fine, and I know several highly competent individuals who run their own email infrastructure. The problem is that they represent the small fraction of individuals and organizations who can do so. Even being extremely generous with the numbers, it appears that less than 20%, and probably less than 15% according to other estimates, can even keep their Exchange servers patched, let alone properly configured.If you think it's still worth the risk, and your organization isn't able to patch, because you want to avoid megacorp email providers or government access to your email, you've made a critical miscalculation. You've essentially decided that it's more important for you to keep your email out of megacorp or government hands than it is to keep i |
Tool | ||
|
2018-11-25 15:48:54 | The Origin of the Term Indicators of Compromise (IOCs) (lien direct) |  I am an historian. I practice digital security, but I earned a bachelor's of science degree in history from the United States Air Force Academy. (1)Historians create products by analyzing artifacts, among which the most significant is the written word.In my last post, I talked about IOCs, or indicators of compromise. Do you know the origin of the term? I thought I did, but I wanted to rely on my historian's methodology to invalidate or confirm my understanding.I became aware of the term "indicator" as an element of indications and warning (I&W), when I attended Air Force Intelligence Officer's school in 1996-1997. I will return to this shortly, but I did not encounter the term "indicator" in a digital security context until I encountered the work of Kevin Mandia.In August 2001, shortly after its publication, I read Incident Response: Investigating Computer Crime, by Kevin Mandia, Chris Prosise, and Matt Pepe (Osborne/McGraw-Hill). I was so impressed by this work that I managed to secure a job with their company, Foundstone, by April 2002. I joined the Foundstone incident response team, which was led by Kevin and consisted of Matt Pepe, Keith Jones, Julie Darmstadt, and me.I Tweeted earlier today that Kevin invented the term "indicator" (in the IR context) in that 2001 edition, but a quick review of the hard copy in my library does not show its usage, at least not prominently. I believe we were using the term in the office but that it had not appeared in the 2001 book. Documentation would seem to confirm that, as Kevin was working on the second edition of the IR book (to which I contributed), and that version, published in 2003, features the term "indicator" in multiple locations.In fact, the earliest use of the term "indicators of compromise," appearing in print in a digital security context, appears on page 280 in Incident Response & Computer Forensics, 2nd Edition. From other uses of the term "indicators" in that IR book, you can observe that IOC wasn't a formal, independent concept at this point, in 2003. In the same excerpt above you see "indicators of attack" mentioned.The first citation of the term "indicators" in the 2003 book shows it is meant as an investigative lead or tip: |
Malware Tool Guideline |
1
We have: 2 articles.
We have: 2 articles.
To see everything:
Our RSS (filtrered)
