[OWASP-SOCFramework-Project] Presentation feedback/comments

Eduardo estevao eduardoeo.azevedo at owasp.org
Mon Nov 19 13:16:53 UTC 2018


Hi Muhammad,

Thanks for the answer.

I'll copy below just the points with questions.

Point 7:
External SOCs can't be centralized or distributed?
Its not that External SOCs can't be centralized/distributed, i think its
just not the point here, if the company is going to use a External SOC it
usually don't matter the constituency of the External SOC, i think (in my
vision) its out of scope in this case.

But this is something that we should discuss during the project, once again
we should setup goals and build the content during the construction of the
project.

Point 10:

My mistake, its probably an idea to put the Threat Hunting part on slide 11
in the process, or it could be discussed between Passive Identification/
Active Identification, basicly my idea is to also include the Threat
Hunting on the process.

Point 18:

I agree its not a standard, but we should recommend maybe with differences
between low/medium/high recommendation on a document, but its not only
related to the presentation, the project should state which documents needs
to be created to have a SOC in place, thats the main idea right? help to
build a SOC, maybe have a few models.


I think is important besides the presentation to setup and start the
project in a more structured way.


Best regards,

Eduardo Azevedo




Em dom, 11 de nov de 2018 às 14:31, Muhammad Naqvi <muhammad.naqvi at owasp.org>
escreveu:

> Hi Eduardo,
>
> Thank you for the feedback, please find below my inline response in Green:
>
> Please let us know will you incorporate this feedback in the presentation?
>
> Hi Павел Таратынов,
>
> I hope your points have also been adressed.
>
> Regards
> Faisal
>
>
> On Sat, Oct 13, 2018, 4:09 PM Eduardo estevao <eduardoeo.azevedo at owasp.org
> wrote:
>
>> Dear Naqvi,
>>
>> One consideration not directly on the presentation.
>>
>> The project is slow moving, we could list the initial points and focus on
>> writing the basic documents and setup a calendar to check if the project is
>> running forward.
>>
>>
>> Regarding the presentation, my opinion:
>>
>> 1. On the modals type the fact that is centralized don't dictates how
>> many set of dashboards in my vision, you could have a centralized SOC, with
>> one Team, one HQ, but multiples set of dashboards and even dashboards for
>> specific customers, or compliance. (Page 4 & 5)
>>
>> Agreed to remove this point
>
>>
>> 2. Another point is the 24x7 its not on the Page 4 slide,
>>
>> if its a global organization or a organization selling SOC services
>> globally, i think is cheaper to have one team in one place 24x7 than have
>> multiple teams with different timezones (Follow the Sun on slide 5)
>>
>> Agreed lets add 24X7
>
>>
>> 3. As if I’m correct on point 2, it’s no good to say that Distributed
>> SOC is the best SOC for Global Organization, i think this recommendation is
>> bad because it depends on a lot of factors, should the organization have
>> Pentesters on all locations? Reverse Malware Engineers on all locations?
>> This could be a very expensive option and probably not 100% the best
>> strategy.
>>
>> Agreed that not the best approach, so lets rephrase last 2 points
> Follow the sun approach may be followed by a global organization to avoid
> shifts
>
>>
>>
>> 4. I think it should have an organizational chart as example, and
>> discuss which positions could be remote or could be shared between
>> locations.  Mittre has a book called "Ten Strategies of a World-Class
>> Cybersecurity Operation Center" (link) on page 45 there is a basic example
>> for the chart, the full organization is discussed on the section 4.2, and
>> in the page 68 there is an example of a SOC integrated with minors SOCs
>> remotely.
>>
>> Org Chart can b added on or after slide 32 titled people & skills
>
>>
>> 5. I recommend the reading of the book above, and the use of this book
>> as a guideline for the project.
>>
>> Agreed
>
>>
>> 6. Also the Centralized and Distributed SOC is a discussion for in-house
>> SOC ( maybe in Hybrid?), so maybe you could separate in the slide 3 the
>> points, my suggestion:
>>
>> • In-house
>>
>> o Centralized
>>
>> o Distributed
>>
>> • Managed
>>
>> • Hybrid
>>
>> External SOCs can't be centralized or distributed?
>
>>
>> 7. I didnt understood the slide 7, the constituency, are you talking
>> about in-house SOC constituency? If so why there a topic saying external?
>> Is a SOC Type? I don’t know and didn’t find anything related on the
>> internet.
>>
>> Here I wanted to say following and we can recategorize as follows:
> External SOC
>  - Constituency (major difference without write access to security
> devices)
> - Managed (major difference with write access to security devices)
>
>
>> 8. I think the Hybrid SOC could be the second to be presented, it had
>> part of the In-House SOC and part of Managed SOC, so it could be more clear
>> to the audience to make a link between the types
>>
>> Normally Hybrid comes after the categories which it is combinition
>
>>
>> 9. On the slide 8, the Managed SOC, another risk is that sometimes it
>> could be out of compliance, so for example you need to check where the
>> vendor is and where the data is stored, some countries has a requirement
>> that the data has to be stored physically in the country.
>>
>> This can be explained in the details of last point i.e. Lack of archiving
>
>>
>> 10. In slide 10, Authority, in Proactive it could include maybe the
>> threat hunting part.
>>
>> Plz. Elaborate, here v r discussing about What authority a SOC Team may
> have
>
>>
>> 11. In slide 16, you could add External Feeds, (Taxii and other formats)
>> and OSINT, IOCs and IOAs collections
>>
>> Agreed
>
>>
>> 12. In slide 19, you could add UEBA, or UBA.
>>
>> Can be mentioned in Monitoring slide 18
>
>>
>> 13. In slide 22, in the Analysis probably it could be defined a
>> signature for the malware or the attack, at least define some IOCs or IOAs
>>
>> Signature Can be mentioned in Response slide 24
> IOCs & IOAs Can be mentioned in Detection slide 21
>
>>
>> 14. In slide 24, the response is probably connected to the IOCs, IOAs or
>> signatures created in the Analysis part.
>>
>> Agreed as Above
>
>>
>> 15. In the slide 29, about  the signatures it could be a validation of
>> the signature and replication of the signature for others (if needed), also
>> I think it’s the moment to check the metrics of the incident.
>>
>> Agreed
>
>>
>> 16. In slide 30, two important metrics are MTTD (Mean time to detect)
>> and MTTR (mean time to respond)
>>
>> Agreed
>
>>
>> 17. In slide 31, it’s very important to have template reports for each
>> service, and the frequency for this reports delivery and for who this
>> reports should go. Eg: Its very very important to have frequent reports
>> with metrics for the stakeholders
>>
>> Can be mentioned in detailed document
>
>>
>> 18. I think it’s important in a moment in the presentation explain which
>> documents are a must in every SOC, such as, a SOC Chart, a SOC Roles &
>> Responsibilities, Tools procedures etc..
>>
>> Its not a standard, its framework we can't mention something like
> mandatory documents, however we can have roles & responsibilities slide
>
>>
>>
>> Em sáb, 6 de out de 2018 às 05:00, Muhammad Naqvi <
>> muhammad.naqvi at owasp.org> escreveu:
>>
>>> Dear Project Team,
>>>
>>> Please send your feedback/ comments on the presentation latest by 15th
>>> October.
>>>
>>> Regards
>>> Muhammad Faisal Naqvi
>>> _______________________________________________
>>> OWASP-SOCFramework-Project mailing list
>>> OWASP-SOCFramework-Project at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-socframework-project
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-socframework-project/attachments/20181119/9c79be7e/attachment-0001.html>


More information about the OWASP-SOCFramework-Project mailing list