Skip to content

Info sources 27#101

Merged
ahouseholder merged 8 commits intoCERTCC:mainfrom
j---:info-sources-27
Feb 5, 2021
Merged

Info sources 27#101
ahouseholder merged 8 commits intoCERTCC:mainfrom
j---:info-sources-27

Conversation

@j---
Copy link
Collaborator

@j--- j--- commented Jan 29, 2021

fixes #27
Because 27 is it's last part, closes #24


Like all SSVC decision points, [*Automatable*](#automatable) should capture the analyst's best understanding of plausible scenarios at the time of the analysis.
An answer of *no* does not mean that it is absolutely inconceivable to automate exploitation in any scenario.
It means the analyst is not able to sketch a plausible path through all four kill chain steps.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sure we address this elsewhere in the discussion, but what are the four Kill Chain steps as we are defining them? Others will vary. Or are we just counting the post-delivery stages of the LM Kill Chain?

Copy link
Collaborator Author

@j--- j--- Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

steps 1-4 of the kill chain [@hutchins2011intelligence] ... These
steps are reconnaissance, weaponization, delivery, and exploitation.

Original definition, basically. First four (of 7) stages, so it is not post-delivery. Source:

@article{hutchins2011intelligence,
  title={Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains},
  author={Hutchins, Eric M and Cloppert, Michael J and Amin, Rohan M},
  journal={Leading Issues in Information Warfare \& Security Research},
  volume={1},
  pages={80},
  year={2011}
}

The last three stages, IIRC, are installation, command and control, and action on objectives.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we note that weaponization might not be strictly necessary as a positive act? I.e., "wormable" vuls turn weaponization into a development process that happens once and then exploitation of vulnerable systems is reliable from that point on. A worm seems to automate recon, delivery, and exploitation, but I'm not sure that automation of the weaponization step was necessary.

I may also be missing nuance in my understanding of how folks use the kill chain model.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If something happens once and then can be copied repeatedly without human intervention, I think that falls under the usual definition of automation. I don't know what "positive act" means there. It was done at some point during the exploit development process. Is that not an act some how? If it can just be copied for each new target, then it's automated. Things like ASLR might interfere with automation here, but again overcoming something like ASLR can be automated.

If you want to suggest additional text for Automation, can you open a new issue?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my confusion arises in that "weaponization" is a verb, but an exploit is an artifact. So automated exploitation can use the resulting artifact even if the production of the artifact (which I'm taking to be what "weaponization" means) itself was not automated.

The automation isn't necessarily doing anything to customize the exploit for the target, so it doesn't feel like weaponization is automated so much as it's just taken out of the process that needs to be automated. But yes, I acknowledge this concern is off-topic for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approve this pull. Seems like for the discussions in scope that I'm good.

Copy link
Contributor

@ahouseholder ahouseholder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a few suggestions as inline comments in the changes. They're open for debate though so I'd be ok if they're given consideration and declined.


Like all SSVC decision points, [*Automatable*](#automatable) should capture the analyst's best understanding of plausible scenarios at the time of the analysis.
An answer of *no* does not mean that it is absolutely inconceivable to automate exploitation in any scenario.
It means the analyst is not able to sketch a plausible path through all four kill chain steps.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we note that weaponization might not be strictly necessary as a positive act? I.e., "wormable" vuls turn weaponization into a development process that happens once and then exploitation of vulnerable systems is reliable from that point on. A worm seems to automate recon, delivery, and exploitation, but I'm not sure that automation of the weaponization step was necessary.

I may also be missing nuance in my understanding of how folks use the kill chain model.

@ahouseholder
Copy link
Contributor

ahouseholder commented Feb 4, 2021

changes in a741837 look good to me

@ahouseholder
Copy link
Contributor

I think all my concerns in this one are addressed. If @cgyarbrough confirms his approval this one should be ok to merge.

@cgyarbrough
Copy link
Contributor

I approve this pull.

@ahouseholder ahouseholder merged commit 914d08b into CERTCC:main Feb 5, 2021
@ahouseholder
Copy link
Contributor

squashed and merged.

@j--- j--- deleted the info-sources-27 branch March 31, 2021 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Information sources for trees Explain how to communicate and share SSVC information

3 participants