There are two issues with regard to accessibility …
(1) How do we make sure that everyone who needs access to the methodology can get access in a way that enables them to use it ?
(2) How do we stop people who are less than worthy getting hold of it and using it to attempt to negate the effects of an examination carried out using it ?
—-
(1) Various formats present themselves -
PDF has been mentioned, and is my preferred choice as it is non-changeable, downloadable, searchable and is a common format across all platforms. It also allows for more favourable tools to be used in development - like, dare I say it, Word - with edit tracking options, version control etc.
HTML is a common format, and if properly done, is searchable, downloadable and is a common format across all platforms. It is a pain to write well though, and unless collaborative work is done using a Wiki will require external version controls … And it is also changeable.
Word Documents - can be locked against changes, downloadable and searchable. Not a universal format, although can be read on all platforms with a little ingenuity …
Any other suggestions ? Plain Text ? RTF ?
—-
(2) A more touchy subject here … Arguably, the methodology is unlikely to contain anything much that can't be found elsewhere, however, I wouldn't like to think that we wrote an anti-forensics check list for the bad guy to work through. On the other hand - if we do it right, it isn't as if it isn't going to turn up on bittorrent from somewhere anyway …
On this I really am open to suggestions …
I don't want to exclude people such as students or other security professionals from accessing it to make sensible use of it, the wider community it benefits, the better.
—-
Feedback please ?
On point 2 my initial feeling is there's little value in restricting access to such a document. I suppose it's the same old chestnut we roasted in another thread when we were talking about restricting access to the forums.
Undoubtedly were such a methodology to become popular there would be cases where it was used as an anti-forensics checklist. How frequently might that happen? Do the benefits outweigh the risks?
If the answer to that last question is "no" is there value in developing a methodology in the first place, given that it's likely to be distributed widely even with some attempt at access control? If the answer is "yes" (i.e. the benefits do outweigh the risks) is there any point in attempting to restrict access?
I think if we press on then it has to remain open and available to all but now is the time to discuss the implications of doing so.
More thoughts please!
Jamie
How do we determine "need" in this case? Certainly examiners "need" but so does oposing counsel, students, instructors, etc.
I'd suggest initially, at least among those doing developing the methodologies to allow an editable format that's cross platform. RTF certainly works. I suspect most can handle M$ 2003. It would exclude Office 2007 docx format and some others.
If we have an access control, I'd think the form could be either technicial or via and editor. By using an editor, I'm thinking each section could have someone responsible for consolidating comments and publishing a semi-cohesive format. (Possibly with multiple choices for wording). Is this too tedious? Can we get enough folks to act as editors?
Anyone else have thoughts?
1. Editing board responsible for final commit of content. Content team leads, one per area. Many contributors.
2. No restrictions. Open source is open source.
Hi, my suggestions
1) organization, I think that an editor board is necessary to guarantee the QA of the document, every member could have a team for developing the assigned tasks (the team could be himself as well). Editor board and teams have to be limited in number of members to keep it manageable but contributes can be from anybody (checked by editor board&teams).
2) document lifecycle, maybe a lifecycle could be useful in order to manage contributes. OSSTMM has an editor team as well (if I don't miss anything).
a) stage1-define targets and publish them (public for contributions from anybody)
b) stage2-contributes collection, evaluation and document's section population (private for ed. board and teams).
This phase needs anyway the opinions' exchange with all the contributors, hence is not so private…
c) deploy-official release of the document, it could be an alpha or beta release to allow comments; if no more comments after a defined number of weeks the release became stable and published (public)
3) editor&fileformat, I prefer a wiki, but it has some limits (i.e. managing versions, etc.), as an editor I would suggest OpenOffice for stage phases of the document
OpenOffice supports ODF ( OASIS OpenDocument/ISO/IEC 26300 File Format ) http//
I would suggest pdf for public releases
Always imho
Cheers
Rob
Rob, I think that those are excellent suggestions …
… with the only exception of the fact that I loathe OpenOffice -)
We are slowly building a list of people who are interested in participating - I think that we should at some arbitrary date in the near future define the editor team based on these initial people, at least for Stage 1 - I think that it would be wise to review after that so that people can reassess how they feel that they can contribute best.
If we set this a week from today ?
Thanks.
I like arbitrary, it will keep us moving.
Remember, if things aren't working we can always adjust in the future. I'm not sure which tools we use is so important that I'll worry about it. This is important to do, I'll go with what ever approaches we come up with.