|
Potato Salad posted:They weren't going over the actual raw logs with their eyes to see if if any info wasn't being consumed Maybe having every celebrities password in the world was a thing their nerds wanted?
|
#
?
May 3, 2018 22:15
|
|
|
|
| # ? May 18, 2024 13:21 |
|
|
Anyone who has worked even tangential to software development can see how this could have happened. *During Story Grooming* Dev1: "What's this 2 point story for creating a module to sanitize log data before storage?" Dev2" "Well, I noticed our debug logs store a pretty low level of detail in clear text." Dev1: "That's only because we're in active development, we'll turn off that logging level by the time we go to prod with real data, let's put this story in the backlog." Then the logging level is never turned down when it goes to prod for some reason (someone forgot, rocky deployment that required a lot of initial troubleshooting, some business support process ended up relying on the logs.) The story exists in backlog hell forgotten until the backlog undergoes grooming and someone has an 'oh poo poo' moment when they realize that this never happened and logging level was never turned down.
|
|
#
?
May 4, 2018 00:52
|
|
|
bull3964 posted:The story exists in backlog hell forgotten until the backlog undergoes grooming So never.
|
|
#
?
May 4, 2018 05:24
|
|
|
Volmarias posted:So never. This guy understands it.
|
|
#
?
May 4, 2018 06:15
|
|
|
7zip has an arbitrary code execution CVE out. If you have vendors that you suspect may be using their code in their deflation libraries, you should probably pressure them for confirmation if 7zip code is being used and if their product is affected. These types of disclosures tend to keep coming up years after the fact as companies realize the code-base they are dependent on is vulnerable but they neglected to update. https://www.cisecurity.org/advisory/a-vulnerability-in-7-zip-could-allow-for-arbitrary-code-execution_2018-049/
|
|
#
?
May 4, 2018 14:04
|
|
|
Lain Iwakura posted:Two weeks ago I made a quip about this: Hey did your talk you were giving at BSides(?) get uploaded anywhere?
|
|
#
?
May 4, 2018 14:47
|
|
|
Thanks Ants posted:Hey did your talk you were giving at BSides(?) get uploaded anywhere? It's on her blog, linked to from the site on her twitter profile.
|
|
#
?
May 4, 2018 17:09
|
|
|
Anyone implemented Swimlane?
|
|
#
?
May 7, 2018 01:19
|
|
|
I have a question/rant. I do the IT for a hotel and one of my jobs is managing their booking engine web server. Basically its a IIS server that sits on the web on https. The dumb-rear end company that does PCI scans tells me we fail IF I leave the Windows firewall on and configured correctly. So they call me every 4 months to turn the firewall OFF (WTF?!) and then run the PCI scan and then we pass and I go put the thing back on. I'd just like to know if I am the dumbass or they are.
|
|
#
?
May 7, 2018 16:00
|
|
|
redeyes posted:I have a question/rant. I do the IT for a hotel and one of my jobs is managing their booking engine web server. Basically its a IIS server that sits on the web on https. The dumb-rear end company that does PCI scans tells me we fail IF I leave the Windows firewall on and configured correctly. So they call me every 4 months to turn the firewall OFF (WTF?!) and then run the PCI scan and then we pass and I go put the thing back on. What are the detailed requirements? What is the pass criteria? What are they scanning for?
|
|
#
?
May 7, 2018 16:03
|
|
|
redeyes posted:I have a question/rant. I do the IT for a hotel and one of my jobs is managing their booking engine web server. Basically its a IIS server that sits on the web on https. The dumb-rear end company that does PCI scans tells me we fail IF I leave the Windows firewall on and configured correctly. So they call me every 4 months to turn the firewall OFF (WTF?!) and then run the PCI scan and then we pass and I go put the thing back on.
|
|
#
?
May 7, 2018 16:14
|
|
|
There is no PCI requirement to NOT have endpoint firewalls. You need to have a zone firewall and endpoint is strongly encouraged, that guy is talking out of his rear end. You'll need to make sure a rule is in place so whatever vulnerability scanner you use can completely bypass it but besides that you're good with it on.
|
|
#
?
May 7, 2018 16:24
|
|
|
It is not unusual to give scanners greater access than normal services to find issues like un-needed services or missing patches that would normally be undiscoverable behind a firewall. Going though an enable/disable schedule is a dumb way to do it though.
|
|
#
?
May 7, 2018 16:38
|
|
|
Vuln scans are for disclosure: you figure out what you're running that may have vulns regardless of other controls by leaving the firewall wide open and (probably) giving it credentials to the endpoint for authenticated scanning. Then you figure out if/when patching is appropriate and if other controls mitigate the risk the in the interim. Pen tests can come through that same channel (sans credentials) if you're trying to simulate someone getting in to a privileged location on your network, but are typically operated from something that has the same level ingress as whatever other normal clients connect in.
|
|
#
?
May 7, 2018 17:14
|
|
|
Have any of you done OSWE or eWPT for web app pentesting certs? Thoughts?
|
|
#
?
May 7, 2018 18:20
|
|
|
My favorite PCI anecdote happened to us just a few months ago. One of our platforms is a creaky old legacy system which depends on an equally old program for doing deploys. Being as old as it is, this deployment app uses an ancient version of SSL when it pushes out new files to the various nodes. Even though this operation takes place entirely within the secured internal network, the PCI auditors were unhappy with the old and potentially insecure cipher, and they threatened to fail the entire company over our use of it. Unfortunately, the deployment app is commercial software that was discontinued years ago, so fixing this wouldn't be as simple as just downloading an upgrade. We were faced with the prospect of ripping it out and reworking everything around a replacement, which we'd probably have to create ourselves. It'd be a surprisingly big and expensive project. But fortunately, the existing deployment app has an option to turn off SSL entirely. So we did that and now our deploys go out (still over the internal network) with no encryption at all. The PCI auditors were satisfied with this, and went away.  Here on the sysadmin team, opinions differ as to whether the PCI auditors were even aware of the irony here, or if they simply never thought any farther than their checkbox for SSL/TLS versions.
|
|
#
?
May 7, 2018 20:43
|
|
|
PCI-DSS says you straight-up cannot use RC4 any more, for anything. I doubt they really thought through it, but their goal was to make sure you are complaint and in that aspect they are correct. It is likely better in the long run to have internal traffic moving in the clear (documented, with risk accepted) than on a weak/broken cipher that gives a false sense of security and distorts risk assessments. FYI if these are windows systems 2008+ you can use the windows firewall to create transparent IPsec tunnels for the specific application traffic on your network and use whatever cipher your heart desires. BangersInMyKnickers fucked around with this message at 20:49 on May 7, 2018 |
|
#
?
May 7, 2018 20:46
|
|
|
Powered Descent posted:
PCI Auditors exist only to tick boxes, so the second opinion is the correct one.
|
|
#
?
May 7, 2018 21:22
|
|
|
CLAM DOWN posted:Have any of you done OSWE or eWPT for web app pentesting certs? Thoughts? Are you asking for more info on the certs themselves because I'd like to know more as well. My boss wants to move two of us into more purple teaming type roles and I don't have *any* knowledge of webapp security stuff beyond OWASP.
|
|
#
?
May 7, 2018 22:17
|
|
|
Last time I ran into PCI-DSS was when the auditors said we should just copy-paste the sentences in the requirements, reword them as statements (Is XYZ done like ABC? -> Do XYZ like ABC) and that would be ideal conformance. Yeah, do not expect critical thinking from the majority of them. It is a big world, so statistically speaking there have to be good PCI auditors somewhere. I would very much like to meet one and find out their perspective.
|
|
#
?
May 7, 2018 22:47
|
|
|
BangersInMyKnickers posted:PCI-DSS says you straight-up cannot use RC4 any more, for anything. I doubt they really thought through it, but their goal was to make sure you are complaint and in that aspect they are correct. It is likely better in the long run to have internal traffic moving in the clear (documented, with risk accepted) than on a weak/broken cipher that gives a false sense of security and distorts risk assessments. For those doing a  about audits, I've bolded the important thing the auditors we're looking for.It should be super clear that they wanted the company to know and, hopefully , act upon the fact you have an They want you to realize that is a stone cold fact and the poo poo needs to be documented rather than some sysadmin guy coming in next year saying "yeah the traffic is encrypted". It technically is, but it's like saying we do ROT13 and that's good enough. I hope the risk was bumped up a bit since even internal does not mean the financial network is truly separated from the rest. EVIL Gibson fucked around with this message at 23:26 on May 7, 2018 |
|
#
?
May 7, 2018 23:18
|
|
|
Thanks for the help, I willquote:configure the Windows firewall to whitelist their IP(s) that's probably fine, and way better than just turning off the Windows firewall altogether. Which is much smarter than this BS routine. I am glad it's kind of standard procedure to let the scanner poo poo have its way around the firewall. We also have another firewall which is internet facing but that allows communication on port 443 and 80 and nothing else but I will whitelist them on it too.
|
|
#
?
May 7, 2018 23:34
|
|
|
EVIL Gibson posted:For those doing a I get what you're saying, but the thing is, the old-rear end encryption in the deployment app was not part of our security arrangements. It was totally extraneous. So what exactly was the security risk it posed by being there, why was that risk large enough to threaten our PCI certification, and how was our security posture improved by switching this traffic to in-the-clear? There was none, it shouldn't have, and it wasn't.
|
|
#
?
May 8, 2018 02:30
|
|
|
The risk is that someone would see that it was being encrypted, and as a result think that it was not a big deal if it ended up being exposed externally.
|
|
#
?
May 8, 2018 03:02
|
|
|
Any OpenVAS nerds in the thread? After years of disliking it because the greenbone UI was designed by a dumb baby I finally broke down and installed it at home to give it a go. Now I'm trying to reconcile these two:  The schedule calls for weekly Wednesday 3 hour window starting 2am, then the task that's configured to use that schedule says it'll kick off at 6am?  Am I reading it wrong?
|
|
#
?
May 8, 2018 13:34
|
|
|
Martytoof posted:Any OpenVAS nerds in the thread? After years of disliking it because the greenbone UI was designed by a dumb baby I finally broke down and installed it at home to give it a go. Now I'm trying to reconcile these two: GMT?
|
|
#
?
May 8, 2018 13:40
|
|
|
Oh, maybe. I thought I had everything set to ET. I'll double check, thanks. e: That was it, thanks. Task was configured for ET but UI was still set to UTC.
|
|
#
?
May 8, 2018 13:45
|
|
|
Everything should be done on UTC IMO. Your user session can adjust for the timezone difference but your internal system clock should always be at UTC+0.
|
|
#
?
May 8, 2018 14:28
|
|
|
Powered Descent posted:I get what you're saying, but the thing is, the old-rear end encryption in the deployment app was not part of our security arrangements. It was totally extraneous. So what exactly was the security risk it posed by being there, why was that risk large enough to threaten our PCI certification, and how was our security posture improved by switching this traffic to in-the-clear? Did the program touch customer data? From how it sounds, it did and that means it brings it into scope. Turns out it was lacking and the "encryption" could barely be considered encryption. RC4 has brought into question if it really did everything properly, including by the person who invented it (re:initial random problems) and it took BEAST for definite proof that yes, it is weak. An executive can now NOT say there is encryption internally. If the risk is accepted, then the exec is on the hook if that data is compromised. Where if the attacker got access to the internal traffic (and only the internal traffic for some reason) the encryption is pretty much plain text and then the company would even be more on the line for lying about not using out of date and not current software. Jabor posted:The risk is that someone would see that it was being encrypted, and as a result think that it was not a big deal if it ended up being exposed externally. This guy is correct.
|
|
#
?
May 8, 2018 15:53
|
|
|
Lain Iwakura posted:Everything should be done on UTC IMO. Your user session can adjust for the timezone difference but your internal system clock should always be at UTC+0. I have to fight this fight every couple of months. Sometimes with the same people. "The UI adjusts the TZ displayed to your desktop settings, so stop setting the system to the local TZ! You're loving up my logs."
|
|
#
?
May 8, 2018 19:06
|
|
|
Proteus Jones posted:I have to fight this fight every couple of months. Sometimes with the same people. One of my goals for 2019 internally is to get us away from using timezones specific to where the servers are located. It's going to be an easy sell to some people and a pain to others.
|
|
#
?
May 8, 2018 19:08
|
|
|
Lain Iwakura posted:One of my goals for 2019 internally is to get us away from using timezones specific to where the servers are located. It's going to be an easy sell to some people and a pain to others. This is a good idea and I really wish I could convince more people to do it.
|
|
#
?
May 8, 2018 19:09
|
|
|
Lain Iwakura posted:One of my goals for 2019 internally is to get us away from using timezones specific to where the servers are located. It's going to be an easy sell to some people and a pain to others.
|
|
#
?
May 8, 2018 19:13
|
|
|
Best of both worlds is to torch the local tz world and force people to spend a little bit of their limited brain power natively understanding what UTC means where they live
|
|
#
?
May 8, 2018 22:04
|
|
|
Potato Salad posted:Best of both worlds is to torch the local tz world and force people to spend a little bit of their limited brain power natively understanding what UTC means where they live Let me tell you of Swatch Internet Time(tm). You see a solar day is divided into 1000 ".beats"....
|
|
#
?
May 8, 2018 22:28
|
|
|
EVIL Gibson posted:Let me tell you of Swatch Internet Time(tm). You see a solar day is divided into 1000 ".beats".... Beat Time Coordinated, or BTC, the first decentralized trust time measure in the block chain...
|
|
#
?
May 8, 2018 22:51
|
|
|
UTC or the lack thereof is the bane of my digital forensics existence. Well, when the app doesn't tell me which it is, anyway. Explaining to the court why it looks like an edit happened before a creation, etc etc. It never stops.
|
|
#
?
May 9, 2018 09:45
|
|
|
large sections of our phone network died a few weeks back because NTP stopped working and enough phones and PBXs clock drifted that they wouldn't talk to each other
|
|
#
?
May 9, 2018 18:17
|
|
|
Same except for ICSS on an off-shore rig (No one bother to configure NTP, god drat telecoms idiots!!!)
|
|
#
?
May 9, 2018 18:25
|
|
|
|
| # ? May 18, 2024 13:21 |
|
|
BangersInMyKnickers posted:large sections of our phone network died a few weeks back because NTP stopped working and enough phones and PBXs clock drifted that they wouldn't talk to each other 
|
|
#
?
May 9, 2018 21:47
|
|
