W dniu 2013-09-07 06:39, Ed Gould pisze:
http://www.securityweek.com/obscurity-not-security-or-it
While obscuring website code, server architecture, and security
mechanisms doesn’t provide bullet-proof security on its own, it can be
effective...
By this point, everyone has probably heard the phrase, “Obscurity is
not security.” Or some variation thereof. Technically, it’s true. No
matter how obscure you make something, it doesn’t make it impossible
to “crack.” It just makes it more difficult. That’s because whatever
you do to obscure something, you can always reverse your way out of it
to get the clear picture again. The time it takes to achieve clarity
just depends on how obscure you make it.
Well,
Sometimes you know (or at least you feel) that your system is not
bullteproof. In such case you could do the following:
a) make your system bullteproof. WRONG. Usually you would already do it
if you could. But you Couldn't.
b) make your system obscure. That makes any attack much more labor
intensive. That's why pentesters demand detailed documentation of your
system, LAN, connections, etc. befor they start their tests. Otherwise
the service is significantly more expensive.
For example that's the reason why some people don't use IBM suggested
UACC(R) for parmlib - no access to parmlib = no chance to read it and
find bad/poor statements.
(fine print: the above is strong simplification. IBM disitinguishes
parts of parmlib and clearly says about possible passwords in the
members - see SAG manual).
It's hard to read RACF db if you know nothing about it, but having the
dataset name and the volser it simplifies looking for improperly
protected volume dump.
Of course obscurity instead of security is definitely not security.
My €0.02
--
Radoslaw Skorupka
Lodz, Poland
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: [email protected]
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
