Re: Yep. Docker Con.
You mean like the containers on mainframes used 40+ years ago?
19 posts • joined 10 Sep 2017
Exchange is, whether people like to admit it or not, one of the top integrated enterprise calendaring tools available. It supports plugins for various web meeting tools (e.g. BlueJeans, WebEx), and a very effective scheduling tool. It even supports managing conference rooms.
Forget the email. It's the calendar that keeps Exchange so popular with managers.
I tried Outlook. It failed the Google Calendar test, unable to display all the calendars shared with me. Thunderbird was the first client on Windows that could work with Exchange, Google, and local calendars. (On macOS, the native calendar worked).
For me, the killer app was calendar, not email. I have to be able to display all my calendars (and those of family members that are delegated to me) in one integrated view. Talking to a few of my peers, they ended up using their mobile phones for such, but given the "we own any android/iOS device that connects to our calendar" trends, that's not very attractive to me.
When I looked at it, the specs seem to imply that the combination headphone/microphone/mini-toslink port is now just a headphone/microphone port. That means my only option for digital audio output may be the HDMI port, which is a lot harder to split into two channels to send into both zone A and zone B of my stereo system.
I like several aspects of the unit, but that item does concern me if confirmed.
Of course, my late 2014 mac mini shows no sign of needing replacement any year soon, so by the time I do replace it, Apple may have another unit out, and my (already ten year old) stereo may be ready for a replacement as well.
Removing the stigma against false positive reporting is important. If you aren't reporting false positives, you aren't reporting real phishing events. Err on the side of reporting. Build that culture of acceptance to presume *any* unanticipated email with links or instructions from the outside is a phish and you'll drop your click rate significantly.
Yes, it's annoying to have to email your team and say "You will receive an email from such'n'such place. It will be about this topic. Please respond to it", but it helps.
In any effort like this, one of the things a good manager wants to know is how do we measure this so we know if it is effective? What is the method to measure improvement? Number of clicks? Number of repeat clicks? As the article says, someone will always click. In one phishing training I saw, the security team member clicked on the link and was literally typing in their live username and password, "to be helpful".
I argue that the critical missing metric is time based. How long until that first report? How long until that first click? Can we get people trained to report these things quickly, alerting the trained staff fast enough that they could actually respond and block the malicious URL before the first click? It's ambitious, but it gives you a real measure of your window of vulnerability and your ability to contain the damage.
When I've talked to companies, the executive leadership are so terrified of insider threats, so out of proportion to the actual risk, that often they create a bigger security risk by giving the security team, the very team most likely to go black hat, massive access to every piece of intellectual property in the company, even if they don't actually need that access, because security.
Then I talk to the black hats of security, penetration testers, and they talk about insider threats as the number one source of problems.
Then I sit down and look at the company, and see that the top source of risk isn't a malicious actor at all, and often isn't even adversarial, but structural due to their failure to invest in basic IT. Surveys like this aren't very useful except for fear mongering and encouraging further black hat activities by people with security jobs.
In my experience, keystroke loggers violate the very rules that they claim to enforce because they always end up capturing passwords.
It's nothing but a black hat in a management suit trying to find a way to capture people's login credentials to corporate resources that the person who setup the logger isn't authorized to access.
With companies sometimes providing corporate phones, or if you use your personal phone, requiring that they load their hooks into it that gives them administrative access to it, one of the most evil monitoring forms is 24/7 location monitoring.
Especially with personal mobile devices where many users are not aware of just how many companies market as a "feature" the ability to know where every person's personal phone is at all times and their location history.
I've had to clean up the mess a pen tester left more than once. They create artificial flags that have nothing to do with the actual valuable data of the corporation, declaring complete success when they get to a resource that is relatively low value (not SOX, not the primary product of the company, not publicly available,...), often engage in dodgy business practices like stepping outside the confines of the test (e.g. engaging in the pen test before they're supposed to start), rarely emulate specific threat actors, often mixing techniques from one threat actor with methods used by other threat actors, completely ignorant of the actual risk profile of the organization, all in an effort to scare people to pay them more money.
In one case, the pen testers required me as a defender to actually not engage in normal defensive actions that were part of my everyday job, like blocking attackers detected through automated reports and systems. Often, pen testers are given these blank check views by requiring the security teams to temporarily disable key defensive systems, at least for the attackers' source IP block.
It's long past time to recognize that a pen test is not a replacement for an actual risk assessment that evaluates all types of risks, adversarial, structural, envrionmental and accidental. Management that I talk to is getting risk fatigue, where they start to see pen testers as chicken little, so the theoretical value of the pen tester, to shock management into paying attention to security, is having the opposite effect, blinding management to a more detailed and strategic view of where the security dollars can be most effectively spent to reduce the overall risk to the company.
Why no one seems to be identifying the real source of risk, which is that Netflix allows you to use an email for contact and billing without verifying that the owner of that email address actually intended to do such a thing is beyond me.
This is simply, Netflix failed to perform due diligence on the account when it was created.
Because perl doesn't dictate that people *must* do things in one way or another, but embraces the notion of empowering the developer, I find people dislike it. Because it allows me to solve problems, I use it. It's also by far the best tool for the problems I'm solving.
Perl has another advantage. It's on every system I need to run my code on, unlike a consistent version of Python.
Also, I find I have a much easier time reading perl code six months later than I can python or ruby because the sigils tell me immediately what is being done. Yes, the very feature that some people hate allows me to much more readily re-read the code *months* after I last looked at it.
What I've seen in Silicon Valley is that those who are younger tend to be employees of the various companies. When the person gets to have outside obligations such as family, they become consultants. So it isn't that those over 28 aren't working in IT. They're there. The younger generation, comes in and makes the same mistakes that were made ten years ago. Then the consultants who have more than ten years experience step in and clean up, but charge consultant rates to do so.
Outside Silicon Valley, you're "too young to get a good rating" until you're at least 30.
Asking Stack Overflow which posts get tagged with which language is like looking at the airplanes that returned from battle in WWII to determine where more armor is needed. It looks at the wrong thing. SO is known as the place to get help with Python. If I'm looking for Perl help, I wouldn't go there, but a Perl forum. Similarly with a number of other languages.
In my career as a consultant, I go to new shops and have to ask what language I should be writing security and system admin scripts in. Thus far, I've never been *permitted* Python, because I was the only one who even began to know it, or it wasn't installed on the systems I needed to run code on. I've nearly always been allowed to use Perl because everyone knows it and it is consistently available on all systems. Those few times when Perl wasn't an option, POSIX awk + POSIX sh was the language pair I had to use.
Biting the hand that feeds IT © 1998–2019