3.7.2.4. User authentication can be achieved by various means, including: • biometrics • cryptographic tokens • pass phrases • passwords • smartcards.
as well as knowing a few basic details about the person for password reset - the Sarah Palin email hack. "3.8.1.26. Where practical, cryptographic products must provide a means of data recovery to allow for recovery of data in circumstances where the encryption key is unavailable due to loss, damage or failure." That was not comforting. --- "3.8.1.46. The requirement for an encryption product to provide a key escrow function, where practical, was issued under a Cabinet directive in July 1998." So who is the keymaster? --- 3.8.2.7. The approved hashing algorithms are: • Message Digest v5 (MD5) • Secure Hashing Algorithms (SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512). MD5 and SHA-1 have known weaknesses and should be phased out: http://www.schneier.com/blog/archives/2005/02/sha1_broken.html http://groups.google.com/group/comp.security.pgp.discuss/msg/8357547aa75d0bcd?pli=1 --- 3.3.1.6. An attacker socially engineers an agency staff member into unwittingly assisting R#175 to compromise a system. Finally found a mention under training, which is encouraging :-) --- The notes about testing are good, but should probably include something getting independent penetration testing done. --- Content filtering doesn't seem to address the DNS poisoning + Man in the Middle technique that many companies use to filter HTTPS content. (not that I think these are a good thing). Also doesn't mention the issues surrounding encrypted content or anonymising proxies. --- Keyboards, Mention of infra red, but not wireless in general --- There are mentions of cabling security issues, but nothing that seems to address: * Monday: cleaner comes in and connects USB or PS/2 keyboard logging device. * Tuesday: cleaner collects device. Having daily or hourly checks of cables is not something users would be likely to adhere to, so you'd probably need something like those crypto key chain things instead. Of course, there are many passwords people might use in the system, so they'd be better off putting them in some kind of wallet, with the master key protected by multiple techniques. On Sat, Oct 25, 2008 at 5:43 PM, Marghanita da Cruz <[EMAIL PROTECTED]> wrote: > Ben wrote: >> >> No search hits for: >> * social engineering >> * impersonate >> >> Am I missing something or does this document miss half of IT security, >> from the word go? > > It might just be that the language is unfamiliar - try authentication and > access control. > >> >> On Mon, Oct 20, 2008 at 12:04 PM, Marghanita da Cruz >> <[EMAIL PROTECTED]> wrote: >>> >>> Amos, >>> >>> You might like to check the Australian Government ICT Security Manual >>> (ISM) >>> it >>> tends to talk at a higher conceptual level than specific applications. >>> But >>> provides useful contextual information...I would be interested in your >>> comments >>> about its relevance/comprehensiveness. >>> <http://www.dsd.gov.au/library/infosec/ism.html> >>> >>> Marghanita >>> >>> Morgan Storey wrote: >>>> >>>> Hi Amos, >>>> >>>> That isn't a bad list, I tend to direct people to >>>> http://sectools.org/vuln-scanners.html even though it is a little >>>> dated, and doesn't mention OpenVAS (Nessus forked and OpenVAS is truly >>>> OSS), I also use Webscarab, Xenu (just a link checker but gives you a >>>> good list of the site), W3af, as it is open source and does some nice >>>> fuzzing through its proxy, Nikto/Wikto and Nmap if it is more than >>>> just web. >>>> These are all just auto tests, they won't find everything and there >>>> are some false finds too, so you also have to have a look at >>>> techniques like sql injection (you can get sql injection tools like >>>> the Acuntix, but it is not cheap), and imho you are better learning >>>> the techniques yourself, cause if you know how a tool works you are so >>>> much better off. >>>> >>>> Regards >>>> >>>> On 10/16/08, Amos Shapira <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I need to find tools to run penetration testing on our external web >>>>> interfaces (a web application and an HTTP-based data interface). >>>>> >>>>> The idea is to be able to run automatic tests on new releases before >>>>> deployment. Stress is on "automatic". >>>>> >>>>> Has anyone here got good experience with such tools? I'm digging >>>>> through >>>>> the net and found lots of lists (e.g. >>>>> >>>>> >>>>> http://www.samurainet.org/blog/2008/05/12/web-application-penetration-testing-my-tools-of-the-trade/) >>>>> but if someone can give some input from their personal experience on >>>>> what's >>>>> worth pursuing and what's a waste of time it'll, well..., might save us >>>>> some >>>>> time. >>>>> >>>>> Thanks, >>>>> >>>>> --Amos >>>>> -- >>>>> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ >>>>> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html >>>>> >>>> >>> >>> -- >>> Marghanita da Cruz >>> http://www.ramin.com.au >>> Phone: (+61)0414 869202 >>> >>> >>> -- >>> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ >>> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html >>> >> > > > -- > Marghanita da Cruz > http://www.ramin.com.au > Phone: (+61)0414 869202 > > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
