|
Top-level
 @stefano @maxinstuff "it's not exposed" is still being difficult for the sake of being difficult. And first level is not authorized nor trained to deal with that; but that was their initial interaction with you. If it was insecure, it would still need to be patched. 3 comments
@stefano @maxinstuff NB: I don't have a strong urge to get into an XKCD 386 situation; I'm happy to just drop it. That being said, I do observe deflection and diversion rather than acceptance. While I agree that first level is, well, first level, and thus tied to tight scripts with little agency, a robust process must be designed to default to secure. As such "unless we can checkbox it we need to look more deeply" is usually the local maxima between time & cost efficiency and secureness.  @RichiH @stefano @maxinstuff If they knew anything about what they were auditing, they could have said “we understand that the VPN makes it difficult to access the server and exploit any security holes, but we need the underlying server to be compliant anyway, in case of anyone fumbling the VPN”, and then when they didn’t understand the version/OS differences, said “write us a couple of lines justifying why this is compliant, and we’ll send it for evaluation and archiving”. |
Gregory's Server
@RichiH @maxinstuff Yes, perhaps my approach wasn't excellent; I could have explained the situation earlier. But the outcome wouldn't have been different. Fundamentally, what saddens me is this average attitude of presumption of guilt. If I don't see SSH, I assume it's vulnerable and therefore I intervene. Unfortunately, this is just one of many experiences in this regard...