Police in Israel are recommending that the state attorney’s office prosecute two 18-year-olds suspected of operating vDOS
Police in Israel are recommending that the state attorney’s office indict and prosecute two 18-year-olds suspected of operating vDOS, until recently the most popular attack service for knocking Web sites offline.
NIST draft publication 800-63B changes the password and MFA rules. I am very excited about these long awaited and very progressive changes. I think those changes will improve overall security of authentication while removing unnecessary burden (periodic password changes!) from IT/security personnel.
- No requirement to periodically change passwords.
- Mandatory validation of newly created password against special list of commonly-used, expected, or compromised passwords.
- No requirement to impose password complexity rules (like combination of letters, numbers, and special characters).
- Email is not allowed to be used as 2nd authentication factor in multi factor authentication.
- Voice and SMS are "discouraged" and will be disallowed as 2nd authentication factor.
Here are some excerpts from the draft:
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):
Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.
Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.
Out-of-band authentication using the PSTN (SMS or voice) is discouraged and is being considered for removal in future editions of this guideline.
DNI: Putin Led Cyber, Propaganda Effort to Elect Trump, Denigrate Clinton https://krebsonsecurity.com/2017/01/dni-putin-led-cyberattack-propaganda-effort-to-elect-trump-denigrate-clinton/
There's a total of 595.2 TB of data exposed on the Internet via publicly accessible MongoDB instances that don't have any form of authentication
A quick search for MongoDB reveals that there are nearly 30,000 instances on the Internet that don't have any authorization enabled. This was actually a bit surprising since by default MongoDB listens on localhost and has done so for a while based on the oldest Github checkin for their mongodb.conf.
Interesting comment on the DNC Hack
The price of bitcoin has hit the $1,000 mark following a booming 2016 where it climbed around 120% from the start of the year until eventually hitting a three-year high.
This article was originally published in The Analogies Project on May 16, 2016
Modern technologies allow a single person to write an application code and publish it on the Web so it will be accessible by millions of users worldwide. Most people know those tools very well: Amazon Web Services, Google Cloud Platform, just to name a few. But technological revolution is not limited just to geeks’ world. The publishing industry went through dramatic changes during recent years, and as a result, a single person is now able to write the manuscript and put it in print – meaning real print like paperback or even hardcover and not just PDF or Kindle. CreateSpace and Lulu are just two examples of such self-publishing platforms.
In both cases, the final result looks like a professional product, at least at first glance. Detailed examination, however, will show a big difference in quality between a self-published and traditionally produced book. I am not against self-publishing at all. In fact, I published my first booklets using Kindle Direct Publishing, and I am still very proud of it. The question is what you are trying to achieve. If you are looking for fast results, and you are an extremely self-disciplined person, familiar with the process of professional publishing, self-publishing might work for you as it works for some best-selling authors. But if you are looking for 100% quality assurance as well as even wider and appreciative audience, professional publication most definitely will provide better results.
“Writing is a solitary occupation, while publication is a group exercise.” – Madeleine Robins
A whole team of experts, including a copy editor, content editor, technical editor, production editor, proofreaders, layout editor, cover designer, sales and marketing will make sure your book eventually looks, reads and sells much better than a self-made amateur creation. Those professionals, besides just doing their job, will communicate with you. They will scrutinize and polish your manuscript, word by word, line by line, paragraph by paragraph, and find and fix tons of misspellings and inaccuracies. You will check their work as well, and accept or sometimes reject their changes, to make sure they did not distort the original content.
Such level of scrutiny is almost impossible to achieve by self-publishing, when an author interacts just with computer programs. In addition, a professional publisher will open the door to an even wider audience and additional markets by using their “tricks” that are not available to self-publishing authors – for example, book translation contracts.
The pitfalls of self-deployment of application code might seem similar to those of book self-publishing (bugs and forgotten open ports in lieu of misspellings and inaccuracies), but the implications are even worse because the application security is at stake. In fact, various aspects of security are at stake.
First of all, confidentiality. When developers deploy their own code, it is never tested for security vulnerabilities. Even if there is a well-established testing process in place, developers, if they have free access to production environment, will always try to find a way to install a patch or change the configuration without testing. And this line of code or open port will make a hacker’s day.
There is another important confidentiality which is often overlooked: insider threat. If a single person has ultimate access to the entire process, from writing the source code to modifying the production environment, such a person essentially has the keys to the kingdom. She or he can implement virtually any backdoor, without fear of ever being caught. In a proper operational setup, where developers can modify the source code but cannot deploy it, and DevOps, on the other hand, can modify the production servers but cannot change the application code, creating backdoors becomes much more difficult task which requires collusion between two or more people. Such setup is called dual control.
And finally, availability threat. This is probably the least obvious area which for some people does not even look like a security subject – mistake! The availability threat is even more real than the confidentiality one. Imagine a situation when there is a serious bug found in production which must be resolved as soon as possible. Developers find the problem and now they know how to fix it. As a first instinct, the easiest and fastest way to do it, especially during an emergency, is to give the developer access to production servers to finish the work and get back to normal. This is a completely wrong approach. What happens with the next release? There is a good chance that the fix will not be included because the developer forgot. It would never happen if the fix was delivered by DevOps because the update will go through a full release process. Such a condition is called separation of duties.
Without implementing dual control and separation of duties in development operations, application security looks like a cheap self-published book: you can read it and understand the text, but there are a lot misspellings and inaccuracies. It’s easy to find self-published books at Amazon by just looking at the price: professional publishers cannot afford to sell their products for $0.99. Sooner or later, hackers will find a “self-published” app on the web using their tools. Thieves always look for the low-hanging fruit.
About The Analogies Project
The aim of the Analogies Project is to help spread the message of information security, and its importance in the modern world.
By drawing parallels between what people already know, or find interesting (such as politics, art, history, theatre, sport, science, music and every day life experiences) and how these relates to information security, we can increase understanding and support across the whole of society.
Why I Joined The Analogies Project
I started writing about application security after I realized there is so little information available publicly so I had to conduct my own researches while it was obvious that other people have done the same things already. The problem still exists because most publications are aimed to expert audience. However, information security is not a theoretical science but rather the art of combining computer technology with human communication and psychology. Basic security principles are simple, they just need to be explained in layman’s terms.
The hack of BT's Prestel email and information system in 1984 (!) shows the cost of using live data for testing. Yes, there were people in 1984 using email! It wasn't as featured as Gmail or Outlook but it was kind of email, and it was hacked because BT personnel were using live data in test systems. I can understand why they made this mistake 30 years ago because back then there was no information security discipline per se, at least not in the same form and scale as we have it now. But I can't understand why many companies still make the same mistake today.